MPI для многоядерности?

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

MPI является стандартом де-факто для крупномасштабных научных вычислений и уже широко используется на многоядерных машинах. Это очень быстро. Взгляните на последний список 500 лучших. Лучшие машины в этом списке имеют в некоторых случаях сотни тысяч процессоров с многопроцессорными двух- и четырехъядерными узлами. Многие из этих машин имеют очень быстрые пользовательские сети (Torus, Mesh, Tree и т. д.) и оптимизированные реализации MPI, которые осведомлены об оборудовании.

Если вы хотите использовать MPI с однокристальной многоядерной машиной, это сработает. На самом деле последние версии Mac OS X поставляются с предустановленным OpenMPI, и вы можете OpenMPI довольно безболезненно на обычной многоядерной Linux-машине. OpenMPI используется в Лос-Аламосе на большинстве их систем. Ливермор использует mvapich на своих Linux-кластерах. Прежде чем углубляться в эту тему, следует иметь в виду, что MPI был разработан для решения крупномасштабных научных задач в системах с распределенной памятью. Многоядерные блоки, с которыми вы имеете дело, вероятно, имеют общую память.

OpenMPI и другие реализации по умолчанию используют разделяемую память для локальной передачи сообщений, поэтому вам не нужно беспокоиться о сетевых издержках при передаче сообщений локальным процессам. Это довольно прозрачно, и я не уверен, откуда другие авторы берут свои опасения по поводу высоких накладных расходов. Предостережение заключается в том, что MPI — не самая простая вещь, которую можно использовать для обеспечения параллелизма на одном многоядерном компьютере. В MPI вся передача сообщений является явной. По этой причине его называют «языком ассемблера» параллельного программирования. Явная связь между процессами непроста, если вы не являетесь опытным специалистом в области HPC и существуют и другие парадигмы, более подходящие для совместной памяти (UPC, OpenMP и хорошие языки, такие как Erlang, чтобы назвать немногие), которые вы могли бы попробовать в первую очередь.

Мой совет — использовать MPI, если вы планируете писать параллельное приложение, для решения которого может потребоваться более одной машины. Вы сможете нормально тестировать и работать с обычным многоядерным блоком, а миграция на кластер будет довольно безболезненной, как только вы наладите там работу. Если вы пишете приложение, которому когда-либо понадобится только одна машина, попробуйте что-нибудь другое. Есть более простые способы использования такого параллелизма.

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

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

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

1) Я мог бы использовать только MPI, рассматривая каждый процессор как собственный «узел», даже если некоторые из них сгруппированы вместе на одной машине.

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

Для конкретной математической задачи, над которой я работал, я сначала протестировал две формулировки на одной многоядерной машине: одну с использованием MPI и одну с использованием потоков POSIX. Как оказалось, реализация MPI была намного эффективнее, давая ускорение близкое к 2 для двухъядерной машины, в отличие от 1,3-1,4 для многопоточной реализации. Для кода MPI мне удалось организовать операции так, чтобы процессоры редко простаивали, оставались занятыми, пока между ними передаются сообщения, и маскировали большую часть задержки при передаче данных. В многопоточном коде я столкнулся со множеством узких мест мьютексов, из-за которых потоки часто сидели и ждали, пока другие потоки завершали свои вычисления. Сохранение балансировки вычислительной нагрузки между потоками, похоже, не помогло этому факту.

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

Нет, на мой взгляд, он не подходит для большей части обработки, которую вы выполняете в многоядерной системе. Накладные расходы слишком высоки, объекты, которые вы передаете, должны быть глубоко клонированы, а передача графов больших объектов для выполнения очень маленьких вычислений очень неэффективна. На самом деле он предназначен для обмена данными между отдельными процессами, которые чаще всего работают в разных областях памяти и чаще всего выполняют длительные вычисления.
Многоядерный процессор — это машина с общей памятью, поэтому есть гораздо более эффективные способы выполнения параллельной обработки, которые не включают копирование объектов и где большинство потоков выполняются в течение очень короткого времени. Например, подумайте о многопоточной быстрой сортировке. Накладные расходы на выделение памяти и копирование данных в поток до того, как их можно будет разделить, будут намного медленнее при использовании MPI и неограниченного количества процессоров, чем быстрая сортировка, работающая на одном процессоре.
В качестве примера. , в Java я бы использовал BlockingQueue (конструкцию с общей памятью) для передачи ссылок объектов между потоками с очень небольшими накладными расходами.
Не то, чтобы у него не было своего места, см., например поисковый кластер Google, использующий передачу сообщений. Но, вероятно, это не та проблема, которую вы пытаетесь решить.

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

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

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

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

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

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

Я использовал некоторые пакеты OSS для (C и C++), которые масштабируются и оптимизируют планирование задач. TBB (строительные блоки резьбы) и Cilk Plus хороши, их легко кодировать и получать приложения на местах. Я также считаю, что они достаточно гибкие, чтобы интегрировать в них другие потоковые технологии на более позднем этапе, если это необходимо (OpenMP и т. д.).

www.threadingbuildingblocks.org www.cilkplus.org