Cel, powód
Po pierwsze, ważne jest, aby zdać sobie sprawę, czym różnią się MPICH i Open-MPI, tj. Że są zaprojektowane tak, aby spełniać różne potrzeby. MPICH ma być wysokiej jakości implementacją referencyjną najnowszego standardu MPI i podstawą do implementacji pochodnych na potrzeby specjalnych zastosowań. Open-MPI jest ukierunkowany na typowy przypadek, zarówno pod względem użytkowania, jak i kanałów sieciowych.
Wsparcie dla technologii sieciowych
Open-MPI dokumentuje tutaj obsługę sieci . MPICH wymienia te informacje w pliku README dystrybuowanym z każdą wersją (np. To jest dla 3.2.1). Zauważ, że ponieważ zarówno Open-MPI, jak i MPICH obsługują OFI(aka libfabric) warstwa sieciowa, obsługują wiele takich samych sieci. Jednak libfabric to wieloaspektowy interfejs API, więc nie każda sieć może być obsługiwana tak samo w obu (np. MPICH ma implementację IBM Blue Gene / Q opartą na OFI, ale nie jestem świadomy równoważnej obsługi w Open-MPI) . Jednak oparte na OFI implementacje zarówno MPICH, jak i Open-MPI działają w pamięci współdzielonej, sieci Ethernet (przez TCP / IP), Mellanox InfiniBand, Intel Omni Path i prawdopodobnie innych sieciach. Open-MPI obsługuje również natywnie obie te i inne sieci (tj. Bez OFI w środku).
W przeszłości częstą skargą dotyczącą MPICH było to, że nie obsługuje InfiniBand, podczas gdy Open-MPI tak. Jednak MVAPICH i Intel MPI (między innymi) - oba są pochodnymi MPICH - obsługują InfiniBand, więc jeśli ktoś chce zdefiniować MPICH jako „MPICH i jego pochodne”, to MPICH ma niezwykle szeroką obsługę sieci, obejmującą zarówno InfiniBand, jak i własne interkonekty takie jak Cray Seastar, Gemini i Aries oraz IBM Blue Gene (/ L, / P i / Q). Open-MPI obsługuje również interkonekt Cray Gemini, ale jego użycie nie jest obsługiwane przez Cray. Niedawno MPICH obsługiwał InfiniBand przez netmod (obecnie przestarzały), ale MVAPICH2 ma rozbudowane optymalizacje, które sprawiają, że jest to preferowana implementacja w prawie wszystkich przypadkach.
Obsługa funkcji z najnowszego standardu MPI
Oś ortogonalna do obsługi sprzętu / platformy to pokrycie standardu MPI. Tutaj MPICH jest zwykle znacznie lepszy. MPICH był pierwszą implementacją każdego wydania standardu MPI, od MPI-1 do MPI-3. Open-MPI dopiero niedawno obsługiwał MPI-3 i uważam, że niektóre funkcje MPI-3 zawierają błędy na niektórych platformach (oczywiście MPICH nie jest wolny od błędów, ale błędy w funkcjach MPI-3 są znacznie mniej powszechne).
Historycznie rzecz biorąc, Open-MPI nie miał całościowego wsparcia dla MPI_THREAD_MULTIPLE, co jest krytyczne dla niektórych aplikacji. Może być obsługiwany na niektórych platformach, ale generalnie nie można zakładać, że działa. Z drugiej strony, MPICH ma wsparcie holistyczne MPI_THREAD_MULTIPLEod wielu lat, chociaż implementacja nie zawsze jest wydajna (zobacz „Blokowanie aspektów w wielowątkowych implementacjach MPI” dla jednej analizy).
Inną cechą, która została zepsuta w Open-MPI 1.x, była jednostronna komunikacja, czyli RMA. Zostało to ostatnio naprawione i jako bardzo ciężki użytkownik tych funkcji uważam, że generalnie działają one dobrze w Open-MPI 3.x (patrz np. Macierz testowa ARMCI-MPI w Travis CI, aby uzyskać wyniki pokazujące, że RMA działa z obie implementacje, przynajmniej we współdzielonej pamięci. Widziałem podobne pozytywne wyniki na Intel Omni Path, ale nie testowałem Mellanox InfiniBand.
Zarządzanie procesem
Jednym z obszarów, w którym Open-MPI był znacznie lepszy, był kierownik procesu. Stara wersja MPICH (MPD) była krucha i trudna w użyciu. Na szczęście był on przestarzały przez wiele lat (zobacz wpis MPICH FAQ po szczegóły). Zatem krytyka MPICH z powodu MPD jest fałszywa.
Menedżer procesów Hydry jest całkiem dobry i ma podobną użyteczność i zestaw funkcji jak ORTE (w Open-MPI), np. Oba obsługują HWLOC do kontroli topologii procesu. Istnieją doniesienia, że uruchamianie procesu Open-MPI jest szybsze niż pochodne MPICH dla większych zadań (ponad 1000 procesów), ale ponieważ nie mam tutaj doświadczenia z pierwszej ręki, nie jestem zadowolony z wyciągania jakichkolwiek wniosków. Takie problemy z wydajnością są zwykle specyficzne dla sieci, a czasem nawet dla komputera.
Odkryłem, że Open-MPI jest bardziej niezawodny, gdy używam MacOS z VPN, tj. MPICH może zawiesić się podczas uruchamiania z powodu problemów z rozpoznawaniem nazwy hosta. Ponieważ jest to błąd, może on zniknąć w przyszłości.
Przenośność plików binarnych
Chociaż zarówno MPICH, jak i Open-MPI są oprogramowaniem typu open source, które można kompilować na wielu różnych platformach, często ważna jest przenośność bibliotek MPI w formie binarnej lub powiązanych z nimi programów.
MPICH i wiele jego pochodnych obsługuje kompatybilność ABI ( strona internetowa ), co oznacza, że binarny interfejs do biblioteki jest stały i dlatego można go skompilować z mpi.hjednej implementacji, a następnie uruchomić z inną. Dzieje się tak nawet w przypadku wielu wersji bibliotek. Na przykład często kompiluję Intel MPI, ale LD_PRELOADwersję rozwojową MPICH w czasie wykonywania. Jedną z największych zalet kompatybilności ABI jest to, że ISV (niezależni dostawcy oprogramowania) mogą wydawać pliki binarne skompilowane tylko dla jednego członka rodziny MPICH.
ABI nie jest jedynym typem kompatybilności binarnej. Scenariusze opisane powyżej zakładają, że użytkownicy wszędzie używają tej samej wersji programu uruchamiającego MPI (zwykle mpirunlub mpiexecrazem z jego demonami węzłów obliczeniowych) i biblioteki MPI. Niekoniecznie tak jest w przypadku kontenerów.
Chociaż Open-MPI nie obiecuje zgodności z ABI, zainwestowali dużo w obsługę kontenerów ( dokumenty , slajdy ). Wymaga to dużej staranności w utrzymaniu kompatybilności między różnymi wersjami programu uruchamiającego MPI, demonami programu uruchamiającego i biblioteką MPI, ponieważ użytkownik może uruchamiać zadania przy użyciu nowszej wersji programu uruchamiającego MPI niż demony programu uruchamiającego w obsłudze kontenerów. Bez szczególnej uwagi na stabilność interfejsu programu uruchamiającego zadania kontenera nie zostaną uruchomione, o ile wersje każdego składnika programu uruchamiającego nie będą zgodne. To nie jest problem nie do pokonania:
Na przykład obejściem używanym przez świat Dockera jest konteneryzacja infrastruktury wraz z aplikacją. Innymi słowy, umieszczasz demona MPI w kontenerze z samą aplikacją, a następnie wymagasz, aby wszystkie kontenery (w tym mpiexec) były w tej samej wersji. Pozwala to uniknąć problemu, ponieważ nie masz już operacji infrastruktury między wersjami.
Dziękuję Ralphowi Castainowi z zespołu Open-MPI za wyjaśnienie mi problemów z kontenerami. Bezpośrednio poprzedzający cytat należy do niego.
Porównanie specyficzne dla platformy
Oto moja ocena na podstawie platformy po platformie:
Mac OS: zarówno Open-MPI, jak i MPICH powinny działać dobrze. Aby uzyskać najnowsze funkcje standardu MPI-3, musisz użyć najnowszej wersji Open-MPI, która jest dostępna w Homebrew. Nie ma powodu, aby myśleć o wydajności MPI, jeśli używasz laptopa Mac.
Linux z pamięcią współdzieloną: Open-MPI i MPICH powinny działać dobrze. Jeśli chcesz wydać wersję, która obsługuje wszystkie MPI-3 lub MPI_THREAD_MULTIPLE, prawdopodobnie potrzebujesz MPICH, chyba że sam zbudujesz Open-MPI, ponieważ np. Ubuntu 16.04 dostarcza tylko starą wersję 1.10 przez APT. Nie znam żadnych znaczących różnic w wydajności między tymi dwiema implementacjami. Oba obsługują optymalizacje z pojedynczą kopią, jeśli pozwala na to system operacyjny.
Linux z Mellanox InfiniBand: użyj Open-MPI lub MVAPICH2. Jeśli chcesz wydać wersję obsługującą wszystkie MPI-3 lub MPI_THREAD_MULTIPLEprawdopodobnie potrzebujesz MVAPICH2. Uważam, że MVAPICH2 działa bardzo dobrze, ale nie wykonałem bezpośredniego porównania z OpenMPI na InfiniBand, po części dlatego, że funkcje, dla których wydajność ma dla mnie największe znaczenie (RMA, czyli jednostronne), zostały w przeszłości zepsute w Open-MPI.
Linux z Intel Omni Path (lub jego poprzednikiem, True Scale): używam MVAPICH2, Intel MPI, MPICH i Open-MPI na takich systemach i wszystkie działają. Intel MPI wydaje się być najbardziej zoptymalizowany, podczas gdy Open-MPI zapewnia najlepszą wydajność wdrożeń open-source, ponieważ mają one dobrze zoptymalizowany back-end oparty na PSM2 . Mam kilka uwag na temat GitHub, jak budować różne implementacje open source, ale takie informacje dość szybko się starzeją.
Superkomputery Cray lub IBM: MPI jest instalowany na tych maszynach automatycznie i jest oparty na MPICH w obu przypadkach. Były demonstracje MPICH na Cray XC40 ( tutaj ) przy użyciu OFI , Intel MPI na Cray XC40 ( tutaj ) przy użyciu OFI, MPICH na Blue Gene / Q przy użyciu OFI ( tutaj ) i Open-MPI na Cray XC40 przy użyciu zarówno OFI, jak i uGNI ( tutaj ), ale żaden z nich nie jest obsługiwany przez dostawcę.
Windows: Nie widzę sensu uruchamiania MPI w systemie Windows z wyjątkiem maszyny wirtualnej z systemem Linux, ale zarówno Microsoft MPI, jak i Intel MPI obsługują system Windows i są oparte na MPICH. Słyszałem doniesienia o udanych kompilacjach MPICH lub Open-MPI przy użyciu podsystemu Windows dla systemu Linux, ale nie mam osobistego doświadczenia.
Uwagi
W pełni ujawniając informacje, obecnie pracuję dla firmy Intel w zakresie badań / poszukiwania ścieżek (tj. Nie pracuję nad żadnym oprogramowaniem Intela), a wcześniej przez pięć lat pracowałem dla Argonne National Lab, gdzie intensywnie współpracowałem z zespołem MPICH.