В какие парадигмы программирования я должен инвестировать, если я хочу, чтобы мой код работал на машинах Petascale в будущем?

Из обзора топ-500 довольно ясно видно, что отрасль имеет тенденцию к экспоненциальному увеличению числа процессорных ядер . Все крупнейшие суперкомпьютеры используют MPI для связи между узлами, хотя не наблюдается явной тенденции к параллелизму на узле, при этом самый простой (но не обязательно самый эффективный) подход для сопоставления отдельного процесса MPI каждому ядру, автоматический распараллеливание из компилятора, OpenMP, pthreads, CUDA, Cilk и OpenCL.

Я один из группы ученых, которые занимаются поддержкой и разработкой кода, который потенциально может быть использован на некоторых из крупнейших суперкомпьютеров в мире. Если предположить, что у разработчика будет ограниченное время, как я буду ориентироваться на будущее, чтобы использовать преимущества самой мощной машины в мире? Какие предположения я должен сделать об архитектуре межсоединения процессов? Какие парадигмы пострадают, когда мы войдем в эру многоядерности? Будут ли разделенные языки глобального адресного пространства доступны "в производстве" на машинах petascale?

Историческая перспектива

На самом деле невозможно сказать, какими будут новые парадигмы в будущем, например, хорошая историческая перспектива, которую я предлагаю прочитать в книге Кена Кеннеди « Подъем и падение ФВЧ» . Кеннеди рассказывает о двух новых моделях, MPI и интеллектуальном компиляторе, и рассказывает о том, как у MPI было достаточно ранних пользователей и гибкости, чтобы доминировать. HPF в конце концов исправила свои проблемы, но было слишком поздно.

Во многих отношениях несколько парадигм, таких как PGAS и OpenMP, следуют той же тенденции HPF. Ранние коды не были достаточно гибкими, чтобы хорошо их использовать, и оставляли много производительности на столе. Но обещание не писать каждую йоту параллельного алгоритма является привлекательной целью. Поэтому стремление к новым моделям всегда преследуется.

Четкие тенденции в оборудовании

В настоящее время успех MPI часто упоминается как тесно связанный с тем, как он моделирует оборудование, на котором он работает. Примерно в каждом узле есть несколько процессов, и передача сообщений в локальные двухточечные или посредством согласованных коллективных операций легко выполняется в пространстве кластера. Из-за этого я не доверяю никому, кто дает парадигму, которая не очень внимательно следит за новыми тенденциями в оборудовании, на самом деле я был убежден в этом мнении работой Vivak Sarakar .

В соответствии с этим здесь есть три тенденции, которые явно продвигаются в новых архитектурах. И позвольте мне прояснить, что сейчас в HPC продается двенадцать различных архитектур. Это меньше, чем 5 лет назад только с x86, поэтому в ближайшие дни появится много возможностей для использования аппаратного обеспечения различными и интересными способами.

• Чипы специального назначения: представьте себе большие векторные блоки как ускорители (см. Билла Дэлли из Nvidia)
• Чипы с низким энергопотреблением: кластеры на основе ARM (для учета энергопотребления)
• Tiling of Chips: подумайте о фишках с разными спецификациями (работа Avant Argwal )

Текущие Модели

Текущая модель на самом деле 3 уровня. Хотя существует много кодов, которые хорошо используют два из этих уровней, немногие появились с использованием всех трех. Я считаю, что для того, чтобы сначала перейти к расширению, нужно вложить средства в определение того, может ли ваш код работать на всех трех уровнях. Это, пожалуй, самый безопасный путь для повторения с современными тенденциями.

Позвольте мне повторить модели и то, как они должны будут измениться, основываясь на предсказанных новых видах оборудования.

распределенный

Игроки на распределенном уровне в основном относятся к языкам MPI и PGAS. MPI сейчас является явным победителем, но языки PGAS, такие как UPC и Chapel, продвигаются вперед. Хорошим показателем является тест HPC Benchmark Challenge. Языки PGAS предоставляют очень элегантные реализации тестов.

Наиболее интересным моментом здесь является то, что, хотя эта модель в настоящее время работает только на уровне узлов, она будет важной моделью внутри узла для плиточных архитектур. Одним из признаков является чип Intel SCC, который в основном действовал как распределенная система. Команда SCC создала собственную реализацию MPI, и многим командам удалось перенести библиотеки сообществ на эту архитектуру.

Но, честно говоря, у PGAS действительно хорошая история для того, чтобы вступить в это пространство. Вы действительно хотите запрограммировать междоузлий MPI, а затем сделать тот же трюк интранода? Одна из больших проблем с этими плиточными архитектурами заключается в том, что они будут иметь разную тактовую частоту на чипах и существенные различия в пропускной способности памяти, поэтому производительные коды должны учитывать это.

Совместная память на узле

Здесь мы видим, что MPI часто «достаточно хорош», но PThreads (и библиотеки, основанные на PThreads, такие как Intel Parallel Building Blocks) и OpenMP по-прежнему используются часто. Распространенное мнение состоит в том, что будет время, когда будет достаточно потоков совместно используемой памяти, чтобы модель сокета MPI сломалась для RPC, или вам понадобится более легкий процесс, выполняющийся на ядре. Уже вы можете видеть признаки того, что системы IBM Bluegene имеют проблемы с MPI с общей памятью.

Как комментирует Мэтт, наибольший прирост производительности для ресурсоемких кодов - это векторизация последовательного кода. Хотя многие полагают, что это верно для ускорителей, это также важно для машин на узлах. Я считаю, что Westmere имеет FPU шириной 4, поэтому без векторизации можно получить только четверть флопов.

Хотя я не вижу, чтобы текущий OpenMP вошел в это пространство, есть место для микросхем с низким энергопотреблением или для тайлов, чтобы использовать больше легких потоков. OpenMP испытывает трудности с описанием того, как работает поток данных, и с увеличением количества потоков я вижу, что эта тенденция становится все более преувеличенной, просто посмотрите на примеры того, что нужно сделать, чтобы получить правильную предварительную выборку с OpenMP.

И OpenMP, и PThreads на уровне, достаточном для курса, могут использовать векторизацию, необходимую для получения хорошего процента пика, но для этого необходимо разбить ваши алгоритмы так, чтобы векторизация была естественной.

Со-процессор

Наконец, появление сопроцессора (GPU, MIC, Cell Acclerator) вступило в силу. Становится ясно, что ни один путь к exascale не будет полным без них. На SC11 каждый участник конкурса Белл использовал их очень эффективно, чтобы добраться до низких петафлопов. Хотя CUDA и OpenCL доминируют на текущем рынке, я надеюсь, что компиляторы OpenACC и PGAS выйдут в космос.

Теперь, чтобы перейти к расширению, одно из предложений - соединить маломощные чипы с множеством сопроцессоров. Это очень хорошо убьет средний уровень текущего стека и будет использовать коды, которые решают проблемы с решением на главном чипе и перекладывают работу на сопроцессоры. Это означает, что для того, чтобы код работал достаточно эффективно, человек должен переосмыслить алгоритмы в терминах ядер (или кодлетов), то есть параллельных фрагментов уровня команд без ветвей. Насколько я знаю, решение этой эволюции довольно широко открыто.

Как это влияет на разработчика приложения

Теперь перейдем к вашему вопросу. Если вы хотите защитить себя от встречных сложностей машин exascale, вы должны сделать несколько вещей:

• Разработайте свои алгоритмы, чтобы соответствовать как минимум трем уровням параллельной иерархии.
• Разработайте свои алгоритмы в терминах ядер, которые можно перемещать между иерархиями.
• Ослабьте вашу потребность в любых последовательных процессах, все эти эффекты будут происходить асинхронно, потому что синхронное выполнение просто невозможно.

Если вы хотите быть эффективными сегодня, MPI + CUDA / OpenCL достаточно хорош, но UPC добивается успеха, поэтому неплохо было бы потратить несколько дней и изучить его. OpenMP помогает вам начать работу, но приводит к проблемам, когда код нуждается в рефакторинге. PThreads требует полностью переписать ваш код в соответствии со своим стилем. Что делает MPI + CUDA / OpenCL текущей лучшей моделью.

Что здесь не обсуждается

Хотя все эти разговоры об exascale хороши, кое-что, на самом деле не обсуждаемое здесь, - это передача данных на машины и обратно. Хотя было много достижений в системах памяти, мы не видим их в товарном кластере (просто слишком дорого). Теперь, когда ресурсоемкие вычисления становятся центром внимания всех суперкомпьютерных конференций, в область с высокой пропускной способностью памяти наверняка придет большее движение.

Это приводит к другой тенденции, которая может произойти (если вовлечь правильные финансирующие агентства). Машины будут становиться все более и более специализированными для требуемого типа вычислений. Мы уже видим, что «ресурсоемкие» машины финансируются NSF, но эти машины находятся на другой трассе, чем Exascale Grand Challenge 2019 года.

Это стало длиннее, чем ожидалось, попросите ссылки, где они вам нужны в комментариях

Давайте начнем с обсуждения стратегии для кода внутреннего кода (вычисления, которые не касаются межсоединения), так как я думаю, что MPI является хорошим выбором для кода внутреннего кода. Я думаю, что бессмысленно говорить об узлах с менее чем 100 ядрами, поэтому, по крайней мере, с текущим GPU или MIC.

Факт в том, что одни только потоки не могут дать вам максимальной производительности на любом современном чипе, потому что вы должны использовать векторное устройство (верно с момента первого Cray). На Intel и AMD вы можете использовать встроенные функции, но они не переносимы и, на мой взгляд, неуклюжи. CUDA и OpenCL имеют векторизацию, встроенную в библиотеку, и позволяют легко добиться максимальной производительности. Все новое оборудование, о котором я знаю, имеет это векторное требование, поэтому любое решение должно учитывать это. Для меня CUDA / OpenCL - это текущий путь.

Далее, все эти машины будут представлять собой NUMA, который сложнее программировать, но я думаю, что стратегия ядра работает. Вы делите работу и данные на небольшие блоки. Это, вероятно, будет автоматически запланировано, как в настоящее время происходит в CUDA и OpenCL, но вы можете указать зависимости. Для задач, которые соответствуют потоковой парадигме, это разделение также может выполняться автоматически. Intel TBB делает это, но я предпочитаю библиотечный подход более высокого уровня, иллюстрируемый Thrust и Cusp , который может быть нацелен на CUDA или (скоро) TBB.

Я постараюсь дать более короткий ответ, чем некоторые из моих уважаемых коллег по этой теме ;-)

Мое послание всем моим студентам всегда заключается в том, что время разработчика более ценно, чем время процессора. Это означает, что если у вас есть время, чтобы преобразовать 100% кода с эффективностью 80% для работы на больших машинах - с использованием подхода высокого уровня - тогда вам будет лучше, чем при использовании трудоемкого низкого уровня подход, который дает вам 100% эффективности на 20% вашего кода. Как следствие, я большой поклонник библиотек высокого уровня. Мой фаворит в этой области - строительные блоки потоков (TBB), так как это позволяет мне смотреть на алгоритмы на самых внешних циклах и на высоком уровне. Он также может делать все то, что вы, возможно, захотите делать с pthreads, не беспокоясь о необходимости иметь дело с функциями ОС и т. Д. Я не фанат подходов, которые смотрят на самые внутренние циклы, потому что это неправильный уровень для использования параллельных ресурсов внутри узла - - так что нет OpenMP,

Я не могу говорить с властью об OpenCL, CUDA и т. Д.

Ранее опубликованные ответы были превосходными, но они были сосредоточены в основном на архитектуре узлов, что, как мне кажется, отражает тот факт, что MPI в большинстве случаев считается достаточным в качестве моделей междоузлиевого программирования, и что в данном случае мы боремся за параллелизм внутри узла.

Вот мои попытки ответить на два вопроса, на которые еще не дан ответ или на которые даны относительно ограниченные ответы:

Какие предположения я должен сделать об архитектуре межсоединения процессов?

Я рассмотрю три свойства сетей:

1. задержка,
2. пропускная способность и
3. параллелизм.

Задержка обратно пропорциональна частоте. Мы знаем, что масштабирование частоты замерло. Следовательно, можно сделать вывод, что латентность вряд ли значительно уменьшится в будущем. Задержка отправки-возврата MPI на Blue Gene / Q составляет около 2 мкс, что соответствует 3200 циклам. Более половины этой задержки приходится на программное обеспечение, но значительная его часть требуется стандартом MPI; расширенная настройка может уменьшить задержку до 1 мкс, особенно если можно утверждать, что подстановочные знаки MPI не будут использоваться.

В любом случае, аппаратная задержка для внедрения пакетов в системах Blue Gene и Cray составляет около 1 мкс. Во всяком случае, увеличение параллелизма на уровне узлов затрудняет поддержание этого числа на таком низком уровне, но я полон оптимизма, что разработчики оборудования найдут способы сохранить задержку менее 5 нас в обозримом будущем.

Пропускная способность сети тривиально увеличивается за счет увеличения количества сетевых соединений. Однако это только часть истории. Один из них помещает 1000 исходящих ссылок на узел и не может их использовать, если процессор (ы) не может управлять сетью с полной пропускной способностью. Например, некоторые узкие места суперкомпьютеров в шине (например, HyperTransport), а не в сети, с точки зрения пропускной способности впрыска.

Нет никаких фундаментальных ограничений пропускной способности сети, только практические. Пропускная способность стоит денег и энергии. При разработке будущих систем разработчикам систем придется учитывать компромиссы между пропускной способностью сети и другими частями машины. Многие коды не ограничены пропускной способностью сети, поэтому маловероятно, что в будущем мы увидим машины с существенно большей пропускной способностью для каждого соединения. Однако полоса пропускания на узел должна увеличиваться пропорционально вычислительной мощности, поэтому для увеличения масштаба необходимо иметь несколько соединений на узел.

Третье свойство сетей, которое часто игнорируется в формальных моделях, - это количество сообщений, которое можно отправить за один раз. Наличие сети с задержкой 1 нс и / или пропускной способностью 1 ТБ / с, которая может отправлять только 1 сообщение за раз, было бы совершенно бесполезным для большинства случаев использования. Важно иметь возможность отправлять множество сообщений из множества потоков одновременно, чтобы сеть не рухнула из-за конкуренции. Системы Cray и Blue Gene теперь достигают скорости свыше 1 Мбит / с (миллион сообщений в секунду). Я не могу вспомнить точные цифры, но оба могут достичь значительной доли максимальной пропускной способности с небольшими сообщениями. Идеальная сеть может быть в состоянии достичь максимальной пропускной способности с сообщениями любого размера, но на практике это невозможно из-за заголовка пакета и связанных с этим накладных расходов на бухгалтерию. Тем не мение,

Это неполный и несовершенный ответ. Другие могут попытаться улучшить это или предложить вещи, которые я должен улучшить.

Будут ли разделенные языки глобального адресного пространства доступны "в производстве" на машинах petascale?

Системы Cray XE, XK и XC имеют компилятор UPC и CAF производственного качества. Системы Blue Gene могут поставляться с XLUPC и XLCAF, но никто не просит об этом, поэтому они не доставляются. PERCS имеет производственные компиляторы XLUPC и XLCAF, но не имеет крупномасштабных установок, доступных для научного сообщества.

Coarrays являются частью Fortran 2008, хотя реализации в Intel и GNU Fortran еще не являются высококачественными. Предполагается, что реализация Intel работает, но она также довольно медленная (об этом есть статья на PGAS12).

Что касается модели программирования PGAS (так как модели программирования - не языки программирования - являются предметом исходного вопроса), библиотека Global Arrays во многих случаях является разумным приближением к качеству продукции. Как среда выполнения, она не так надежна, как MPI, но MPI довольно уникален с точки зрения качества реализации. Реализация ARMCI-MPI в ARMCI делает глобальные массивы намного более стабильными, хотя в некоторых случаях и медленнее.

Относительно легко реализовать конструкции в стиле PGAS с использованием качества производства с использованием MPI-3 RMA. Если кто-то отправит новый вопрос по этому поводу, я был бы рад ответить на него.

Действительно огромное количество ядер также открывает тривиальную, но удивительно полезную перспективу - просто использовать ее для запуска многих итераций всего моделирования.

В настоящее время значительная часть вычислительных исследований сводится к сканированию некоторого пространства параметров, скринингу большого пула начальных условий или вычислению распределения некоторого результата способом повторной выборки; все эти задачи смущающе параллельны, таким образом, доказательство Амдала.

Я подозреваю, что даже самые продуманные ответы на этот вопрос устареют через пять-десять лет. Учитывая неопределенность будущих парадигм программирования, возможно, не стоит тратить много времени на предварительную оптимизацию вашей кодовой базы.

Я как раз собирался опубликовать этот ответ на этот вопрос , но он был закрыт как дубликат этого, так что вот так:

Это может показаться немного соломоничным, но, по моему опыту, будущее принадлежит гибридным подходам, в которых несколько многоядерных узлов с общей памятью, на которых запущены многопоточные ядра, соединены через парадигму распределенной памяти, такую ​​как MPI.

Однако есть несколько проблем, и они вообще не связаны с аппаратным обеспечением. Прежде всего, большинство параллельных программистов вкладывают значительные средства в коды типа MPI и очень неохотно будут первыми, кто заново реализует части или всю свою базу кода с использованием новой парадигмы. Отсутствие людей, использующих подходы с разделяемой памятью, приводит к более медленному прогрессу в алгоритмах для этой области, что делает любые инвестиции кажущимися еще более бессмысленными.

Вторая проблема заключается в том, что все ассоциируют параллелизм с общей памятью с OpenMP . Хотя OpenMP является хорошим быстрым и грязным способом решения небольших простых задач на небольшом числе процессоров, это абсолютно ужасная модель программирования для реального параллелизма с общей памятью. Хотя в какой-то момент мы все изучили ряд простых и эффективных парадигм параллельного программирования, например, пулы потоков или планировщики , их нелегко реализовать с помощью OpenMP, и, честно говоря, это не тот тип параллелизма, который OpenMP побуждает программистов использовать.

Таким образом, барьер для перехода от чисто распределенной памяти к парадигме чисто / частично разделяемой памяти достаточно высок. Если вы хотите эффективно использовать потоки, вы должны забыть об OpenMP и самостоятельно управлять потоками и параллелизмом (привет, pthreads , до свидания, Fortran).

Но зачем вообще переходить на гибридный подход? Что ж, хотя MPI масштабируется до тысяч ядер, базовая модель - модель синхронности с фиксированным шагом и статические шаблоны связи. Это хорошо для некоторых задач, например, моделирования миллиардов частиц, но не оптимально для более сложных или более мелких задач. Парадигмы общей памяти значительно упрощают динамическую балансировку нагрузки и / или асинхронную связь, но для этого требуются значительные усилия по программированию.