Назначение
Во-первых, важно понять, чем отличаются 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) , Однако реализации MPI и 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) был хрупким и сложным в использовании. К счастью, в течение многих лет он устарел (подробности см. В FAQ по 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 является то, что независимые поставщики программного обеспечения могут выпускать двоичные файлы, скомпилированные только для одного члена семейства 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 Subsystem для Linux , но у меня нет личного опыта.
Примечания
В полном объеме, в настоящее время я работаю в Intel в сфере исследований / поиска путей (т.е. я не работаю над какими-либо программными продуктами Intel) и ранее работал в Argonne National Lab в течение пяти лет, где я активно сотрудничал с командой MPICH.