Цель
Во-первых, важно понять, чем отличаются MPICH и Open-MPI, т. Е. Что они предназначены для удовлетворения разных потребностей. Предполагается, что MPICH будет высококачественной эталонной реализацией последнего стандарта MPI и основой для производных реализаций для удовлетворения потребностей специального назначения. Open-MPI нацелен на общий случай как с точки зрения использования, так и с точки зрения сетевых каналов.
Поддержка сетевых технологий
Open-MPI документирует свою поддержку сети здесь . MPICH перечисляет эту информацию в README, распространяемом с каждой версией (например, это для 3.2.1). Обратите внимание: поскольку и Open-MPI, и MPICH поддерживают OFI(он же libfabric) сетевой уровень, они поддерживают многие из тех же сетей. Однако libfabric является многогранным API, поэтому не каждая сеть может поддерживаться одинаково в обоих (например, MPICH имеет реализацию IBM Blue Gene / Q на основе OFI, но я не знаю об эквивалентной поддержке в Open-MPI) , Однако реализации MPICH и Open-MPI на основе OFI работают с общей памятью, Ethernet (через TCP / IP), Mellanox InfiniBand, Intel Omni Path и, вероятно, другими сетями. Open-MPI также поддерживает обе эти и другие сети изначально (т.е. без OFI в середине).
В прошлом обычная жалоба на MPICH заключалась в том, что он не поддерживает InfiniBand, тогда как Open-MPI поддерживает. Однако MVAPICH и Intel MPI (среди прочих) - оба являются производными от MPICH - поддерживают InfiniBand, поэтому, если кто-то хочет определить MPICH как «MPICH и его производные», тогда MPICH имеет чрезвычайно широкую поддержку сети, включая как InfiniBand, так и проприетарный межблочные соединения, такие как Cray Seastar, Gemini и Aries, а также IBM Blue Gene (/ L, / P и / Q). Open-MPI также поддерживает межсоединение Cray Gemini, но его использование не поддерживается Cray. Совсем недавно MPICH поддерживал InfiniBand через netmod (теперь устаревший), но MVAPICH2 имеет обширные оптимизации, которые делают его предпочтительной реализацией почти во всех случаях.
Поддержка функций из последнего стандарта MPI
Ортогональная ось поддержки оборудования / платформы - это покрытие стандарта MPI. Здесь MPICH обычно намного лучше. MPICH был первой реализацией каждого отдельного выпуска стандарта MPI, от MPI-1 до MPI-3. Open-MPI только недавно поддержал MPI-3, и я обнаружил, что некоторые функции MPI-3 содержат ошибки на некоторых платформах (MPICH, конечно, не свободен от ошибок, но ошибки в функциях MPI-3 встречаются гораздо реже).
Исторически Open-MPI не имел комплексной поддержки MPI_THREAD_MULTIPLE, что критично для некоторых приложений. Он может поддерживаться на некоторых платформах, но, как правило, нельзя предполагать, что он работает. С другой стороны, MPICH имеет комплексную поддержку в MPI_THREAD_MULTIPLEтечение многих лет, хотя реализация не всегда высокопроизводительна (см. «Аспекты блокировки в многопоточных реализациях MPI» для одного анализа).
Еще одна функция, которая была нарушена в Open-MPI 1.x, - это односторонняя связь, также известная как RMA. Совсем недавно это было исправлено, и я, как очень интенсивный пользователь этих функций, обнаружил, что они обычно хорошо работают в Open-MPI 3.x (см., Например, тестовую матрицу ARMCI-MPI в Travis CI для получения результатов, показывающих, что RMA работает с Обе реализации, по крайней мере, с разделяемой памятью.Я видел аналогичные положительные результаты на Intel Omni Path, но не тестировал Mellanox InfiniBand.
Управление процессом
Одна из областей, в которой Open-MPI раньше значительно превосходила, - это диспетчер процессов. Старый пусковой механизм MPICH (MPD) был хрупким и трудным в использовании. К счастью, он устарел в течение многих лет (подробности см. В разделе часто задаваемых вопросов MPICH ). Таким образом, критика MPICH из-за MPD ложна.
Менеджер процессов Hydra довольно хорош и имеет такое же удобство использования и набор функций, что и ORTE (в Open-MPI), например, оба поддерживают HWLOC для управления топологией процесса. Есть сообщения о том, что процесс Open-MPI запускается быстрее, чем производные MPICH для более крупных задач (более 1000 процессов), но, поскольку у меня нет личного опыта здесь, мне неудобно делать какие-либо выводы. Такие проблемы с производительностью обычно зависят от сети, а иногда даже от машины.
Я обнаружил, что Open-MPI более надежен при использовании MacOS с VPN, т.е. MPICH может зависать при запуске из-за проблем с разрешением имени хоста. Поскольку это ошибка, эта проблема может исчезнуть в будущем.
Двоичная переносимость
Хотя и MPICH, и Open-MPI являются программным обеспечением с открытым исходным кодом, которое может быть скомпилировано на широком спектре платформ, переносимость библиотек MPI в двоичной форме или программ, связанных с ними, часто важна.
MPICH и многие его производные поддерживают совместимость с ABI ( веб-сайт ), что означает, что двоичный интерфейс к библиотеке постоянен, и поэтому можно скомпилировать с mpi.hодной реализацией, а затем запустить с другой. Это верно даже для нескольких версий библиотек. Например, я часто компилирую Intel MPI, но LD_PRELOADразрабатываю версию MPICH во время выполнения. Одним из больших преимуществ совместимости с ABI является то, что ISV (независимые поставщики программного обеспечения) могут выпускать двоичные файлы, скомпилированные только для одного члена семейства MPICH.
ABI - не единственный тип двоичной совместимости. Описанные выше сценарии предполагают, что пользователи везде используют одну и ту же версию средства запуска MPI (обычно mpirunили mpiexecвместе с его демонами вычислительного узла) и библиотеку MPI. Это не обязательно относится к контейнерам.
Хотя Open-MPI не обещает совместимости с ABI, они вложили значительные средства в поддержку контейнеров ( документы , слайды ). Это требует большой осторожности в поддержании совместимости между различными версиями средства запуска MPI, демонов запуска и библиотеки MPI, поскольку пользователь может запускать задания, используя более новую версию средства запуска MPI, чем демоны запуска в поддержке контейнера. Без должного внимания к стабильности интерфейса программы запуска контейнерные задания не будут запускаться, если версии каждого компонента программы запуска не будут совместимы. Это не непреодолимая проблема:
Обходной путь, используемый миром Docker, например, заключается в контейнеризации инфраструктуры вместе с приложением. Другими словами, вы включаете демон MPI в контейнер с самим приложением, а затем требуете, чтобы все контейнеры (включая mpiexec) были одной версии. Это позволяет избежать проблемы, поскольку у вас больше нет операций с кросс-версией инфраструктуры.
Я благодарен Ральфу Кастейну из команды Open-MPI за объяснение мне проблем с контейнером. Непосредственно предыдущая цитата принадлежит ему.
Сравнение платформ
Вот моя оценка для каждой платформы:
Mac OS: и Open-MPI, и MPICH должны работать нормально. Чтобы получить новейшие функции стандарта MPI-3, вам необходимо использовать последнюю версию Open-MPI, доступную на Homebrew. Нет причин думать о производительности MPI, если вы работаете на ноутбуке Mac.
Linux с разделяемой памятью: и Open-MPI, и MPICH должны работать нормально. Если вам нужна версия выпуска, которая поддерживает все MPI-3 или MPI_THREAD_MULTIPLE, вам, вероятно, понадобится MPICH, если вы сами не создадите Open-MPI, потому что, например, Ubuntu 16.04 предоставляет только старую версию 1.10 через APT. Мне не известно о каких-либо существенных различиях в производительности между двумя реализациями. Оба поддерживают оптимизацию с использованием одной копии, если это позволяет ОС.
Linux с Mellanox InfiniBand: используйте Open-MPI или MVAPICH2. Если вам нужна версия выпуска, которая поддерживает все MPI-3 или MPI_THREAD_MULTIPLE, вам, скорее всего, понадобится MVAPICH2. Я считаю, что MVAPICH2 работает очень хорошо, но не проводил прямого сравнения с OpenMPI на InfiniBand, отчасти потому, что функции, для которых производительность имеет для меня наибольшее значение (RMA, также известный как односторонний), в прошлом были нарушены в Open-MPI.
Linux с Intel Omni Path (или его предшественник, True Scale): я использовал MVAPICH2, Intel MPI, MPICH и Open-MPI в таких системах, и все они работают. Intel MPI стремится к максимальной оптимизации, тогда как Open-MPI обеспечивает лучшую производительность среди реализаций с открытым исходным кодом, поскольку они имеют хорошо оптимизированную внутреннюю часть на основе PSM2 . У меня есть несколько заметок на GitHub о том, как создавать различные реализации с открытым исходным кодом, но такая информация довольно быстро устаревает.
Суперкомпьютеры Cray или IBM: MPI устанавливается на этих машинах автоматически, и в обоих случаях он основан на MPICH. Были демонстрации MPICH на Cray XC40 ( здесь ) с использованием OFI , Intel MPI на Cray XC40 ( здесь ) с использованием OFI, MPICH на Blue Gene / Q с использованием OFI ( здесь ) и Open-MPI на Cray XC40 с использованием как OFI, так и uGNI ( здесь ), но ни один из них не поддерживается производителем.
Windows: Я не вижу смысла запускать MPI в Windows, кроме как через виртуальную машину Linux, но и Microsoft MPI, и Intel MPI поддерживают Windows и основаны на MPICH. Я слышал сообщения об успешных сборках MPICH или Open-MPI с использованием подсистемы Windows для Linux, но не имею личного опыта.
Ноты
К слову сказать, в настоящее время я работаю в Intel в области исследования / поиска путей (т. Е. Я не работаю над какими-либо программными продуктами Intel), а ранее работал в Аргоннской национальной лаборатории в течение пяти лет, где я активно сотрудничал с командой MPICH.