Призначення
По-перше, важливо визнати, наскільки 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) . Однак реалізовані на базі OFI реалізації MPICH і Open-MPI працюють у спільній пам'яті, 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, Близнюки та Овен, а також 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 FAQ ). Таким чином, критика MPICH через MPD є хибною.
Менеджер процесів Hydra досить хороший і має схожі зручності та функції, як ORTE (у Open-MPI), наприклад, обидва підтримують HWLOC для контролю над топологією процесу. Є повідомлення про те, що процес відкритого 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 aka однобічна), були порушені в 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 VM, але і Microsoft MPI, і Intel MPI підтримують Windows і працюють на базі MPICH. Я чув повідомлення про успішні збірки MPICH або Open-MPI, що використовують підсистему Windows для Linux, але не маю особистого досвіду.
Примітки
Повністю розкриваючи інформацію, я в даний час працюю в Intel в якості науково-дослідної роботи (тобто я не працюю над будь-якими програмними продуктами Intel) і раніше працював у Національній лабораторії Argonne протягом п'яти років, де я співпрацював з командою MPICH.