Kann jemand die Unterschiede zwischen den OpenMPI- und MPICH-Implementierungen von MPI erläutern? Welche der beiden ist eine bessere Implementierung?

Zweck

Zunächst ist es wichtig zu erkennen, wie unterschiedlich MPICH und Open-MPI sind, dh dass sie auf unterschiedliche Anforderungen zugeschnitten sind. MPICH soll eine qualitativ hochwertige Referenzimplementierung des neuesten MPI-Standards und die Grundlage für derivative Implementierungen sein, um spezielle Anforderungen zu erfüllen. Open-MPI zielt auf den allgemeinen Fall ab, sowohl in Bezug auf die Nutzung als auch auf die Netzwerkleitungen.

Unterstützung für Netzwerktechnologie

Open-MPI dokumentiert ihre Netzwerk - Unterstützung hier . MPICH listet diese Informationen in der Readme mit jeder Version verteilt (zB dies ist für 3.2.1). Beachten Sie dies, da sowohl Open-MPI als auch MPICH das OFI unterstützen(aka libfabric) Netzwerkschicht, sie unterstützen viele der gleichen Netzwerke. Libfabric ist jedoch eine facettenreiche API, sodass möglicherweise nicht jedes Netzwerk in beiden gleich unterstützt wird (z. B. hat MPICH eine OFI-basierte IBM Blue Gene / Q-Implementierung, mir ist jedoch keine gleichwertige Unterstützung in Open-MPI bekannt). . Die OFI-basierten Implementierungen von MPICH und Open-MPI arbeiten jedoch mit Shared Memory, Ethernet (über TCP / IP), Mellanox InfiniBand, Intel Omni Path und wahrscheinlich anderen Netzwerken. Open-MPI unterstützt sowohl diese als auch andere Netzwerke nativ (dh ohne OFI in der Mitte).

In der Vergangenheit war eine häufige Beschwerde über MPICH, dass InfiniBand nicht unterstützt wird, während dies bei Open-MPI der Fall ist. MVAPICH und Intel MPI (unter anderem) - beide sind MPICH-Derivate - unterstützen InfiniBand. Wenn man also bereit ist, MPICH als "MPICH und seine Derivate" zu definieren, bietet MPICH eine äußerst breite Netzwerkunterstützung, einschließlich InfiniBand und proprietär Verbindungen wie Cray Seastar, Gemini und Aries sowie IBM Blue Gene (/ L, / P und / Q). Open-MPI unterstützt auch die Cray Gemini-Verbindung, ihre Verwendung wird jedoch von Cray nicht unterstützt. In jüngerer Zeit unterstützte MPICH InfiniBand über einen Netmod (jetzt veraltet), aber MVAPICH2 verfügt über umfangreiche Optimierungen, die es in fast allen Fällen zur bevorzugten Implementierung machen.

Funktionsunterstützung nach dem neuesten MPI-Standard

Eine orthogonale Achse zur Hardware- / Plattformunterstützung ist die Abdeckung des MPI-Standards. Hier ist MPICH in der Regel weit und breit überlegen. MPICH war die erste Implementierung jeder einzelnen Version des MPI-Standards von MPI-1 bis MPI-3. Open-MPI hat MPI-3 erst kürzlich unterstützt, und ich finde, dass einige MPI-3-Funktionen auf einigen Plattformen fehlerhaft sind (MPICH ist natürlich nicht fehlerfrei, aber Fehler in MPI-3-Funktionen waren weitaus seltener).

In der Vergangenheit hatte Open-MPI keine ganzheitliche Unterstützung MPI_THREAD_MULTIPLE, was für einige Anwendungen von entscheidender Bedeutung ist. Es wird möglicherweise auf einigen Plattformen unterstützt, kann jedoch im Allgemeinen nicht als funktionsfähig angesehen werden. Auf der anderen Seite hat MPICH seit MPI_THREAD_MULTIPLEvielen Jahren ganzheitliche Unterstützung , obwohl die Implementierung nicht immer leistungsstark ist (siehe "Sperren von Aspekten in Multithread-MPI-Implementierungen"). für eine Analyse).

Eine weitere Funktion, die in Open-MPI 1.x nicht funktioniert hat, war die einseitige Kommunikation, auch bekannt als RMA. Dies wurde in jüngerer Zeit behoben, und ich stelle als sehr starker Benutzer dieser Funktionen fest, dass sie in Open-MPI 3.x im Allgemeinen gut funktionieren (siehe z. B. die ARMCI-MPI-Testmatrix in Travis CI für Ergebnisse, die zeigen, dass RMA funktioniert Beide Implementierungen, zumindest im Shared Memory. Ich habe ähnliche positive Ergebnisse auf Intel Omni Path gesehen, aber Mellanox InfiniBand nicht getestet.

Prozessmanagement

Ein Bereich, in dem Open-MPI früher deutlich überlegen war, war der Prozessmanager. Der alte MPICH-Start (MPD) war spröde und schwer zu bedienen. Glücklicherweise ist es seit vielen Jahren veraltet ( Details finden Sie im MPICH-FAQ-Eintrag ). Kritik an MPICH wegen MPD ist daher falsch.

Der Hydra-Prozessmanager ist recht gut und verfügt über eine ähnliche Benutzerfreundlichkeit und ähnliche Funktionen wie ORTE (in Open-MPI), z. B. unterstützen beide HWLOC zur Steuerung der Prozesstopologie. Es gibt Berichte darüber, dass der Start von Open-MPI-Prozessen bei größeren Aufträgen (über 1000 Prozesse) schneller ist als bei MPICH-Derivaten. Da ich hier jedoch keine Erfahrungen aus erster Hand habe, kann ich keine Schlussfolgerungen ziehen. Solche Leistungsprobleme sind normalerweise netzwerkspezifisch und manchmal sogar maschinenspezifisch.

Ich habe festgestellt, dass Open-MPI bei Verwendung von MacOS mit einem VPN robuster ist, dh MPICH kann aufgrund von Problemen mit der Auflösung des Hostnamens beim Start hängen bleiben. Da dies ein Fehler ist, kann dieses Problem in Zukunft verschwinden.

Binäre Portabilität

Während sowohl MPICH als auch Open-MPI Open-Source-Software sind, die auf einer Vielzahl von Plattformen kompiliert werden kann, ist die Portabilität von MPI-Bibliotheken in binärer Form oder von mit ihnen verknüpften Programmen häufig wichtig.

MPICH und viele seiner Derivate unterstützen die ABI-Kompatibilität ( Website ). Dies bedeutet, dass die binäre Schnittstelle zur Bibliothek konstant ist und daher mpi.hvon einer Implementierung aus kompiliert und dann mit einer anderen ausgeführt werden kann. Dies gilt auch für mehrere Versionen der Bibliotheken. Zum Beispiel kompiliere ich häufig Intel MPI, aber LD_PRELOADzur Laufzeit eine Entwicklungsversion von MPICH. Einer der großen Vorteile der ABI-Kompatibilität besteht darin, dass ISVs (Independent Software Vendors) Binärdateien freigeben können, die nur für ein Mitglied der MPICH-Familie kompiliert wurden.

ABI ist nicht die einzige Art der Binärkompatibilität. In den oben beschriebenen Szenarien wird davon ausgegangen, dass Benutzer überall dieselbe Version des MPI-Starters (normalerweise mpirunoder mpiexeczusammen mit seinen Rechenknotendämonen) und der MPI-Bibliothek verwenden. Dies ist bei Containern nicht unbedingt der Fall.

Open-MPI verspricht zwar keine ABI-Kompatibilität, hat jedoch stark in die Unterstützung von Containern ( Dokumente , Folien ) investiert . Dies erfordert große Sorgfalt bei der Aufrechterhaltung der Kompatibilität zwischen verschiedenen Versionen des MPI-Launchers, der Launcher-Daemons und der MPI-Bibliothek, da ein Benutzer möglicherweise Jobs mit einer neueren Version des MPI-Launcher als den Launcher-Daemons in der Containerunterstützung starten kann. Ohne sorgfältige Berücksichtigung der Stabilität der Startschnittstelle werden Containerjobs nur gestartet, wenn die Versionen der einzelnen Komponenten des Startprogramms kompatibel sind. Dies ist kein unüberwindbares Problem:

Die von der Docker-Welt verwendete Problemumgehung besteht beispielsweise darin, die Infrastruktur zusammen mit der Anwendung zu containerisieren. Mit anderen Worten, Sie fügen den MPI-Dämon mit der Anwendung selbst in den Container ein und verlangen dann, dass alle Container (einschließlich mpiexec) dieselbe Version haben. Dadurch wird das Problem vermieden, da Sie keine versionierungsübergreifenden Infrastrukturvorgänge mehr haben.

Ich danke Ralph Castain vom Open-MPI-Team dafür, dass er mir die Containerprobleme erklärt hat. Das unmittelbar vorhergehende Zitat ist sein.

Plattformspezifischer Vergleich

Hier ist meine Bewertung auf Plattform-für-Plattform-Basis:

• Mac OS: Sowohl Open-MPI als auch MPICH sollten einwandfrei funktionieren. Um die neuesten Funktionen des MPI-3-Standards zu erhalten, müssen Sie eine aktuelle Version von Open-MPI verwenden, die bei Homebrew erhältlich ist. Es gibt keinen Grund, über die MPI-Leistung nachzudenken, wenn Sie auf einem Mac-Laptop arbeiten.

• Linux mit Shared Memory: Sowohl Open-MPI als auch MPICH sollten einwandfrei funktionieren. Wenn Sie eine Release-Version wünschen, die MPI-3 oder MPI_THREAD_MULTIPLE unterstützt, benötigen Sie wahrscheinlich MPICH, es sei denn, Sie erstellen Open-MPI selbst, da Ubuntu 16.04 beispielsweise nur die alte Version 1.10 über APT bereitstellt. Mir sind keine signifikanten Leistungsunterschiede zwischen den beiden Implementierungen bekannt. Beide unterstützen Einzelkopieoptimierungen, sofern das Betriebssystem dies zulässt.

• Linux mit Mellanox InfiniBand: Verwenden Sie Open-MPI oder MVAPICH2. Wenn Sie eine Release-Version wünschen, die MPI-3 oder unterstützt MPI_THREAD_MULTIPLE, benötigen Sie wahrscheinlich MVAPICH2. Ich finde, dass MVAPICH2 sehr gut funktioniert, aber keinen direkten Vergleich mit OpenMPI auf InfiniBand durchgeführt hat, auch weil die Funktionen, für die die Leistung für mich am wichtigsten ist (RMA alias einseitig), in der Vergangenheit in Open-MPI gebrochen wurden.

• Linux mit Intel Omni Path (oder seinem Vorgänger True Scale): Ich habe MVAPICH2, Intel MPI, MPICH und Open-MPI auf solchen Systemen verwendet und alle funktionieren. Intel MPI ist in der Regel am optimiertesten, während Open-MPI die beste Leistung der Open-Source-Implementierungen liefert, da sie über ein gut optimiertes PSM2- basiertes Back-End verfügen . Ich habe einige Hinweise zu GitHub zum Erstellen verschiedener Open-Source-Implementierungen, aber solche Informationen sind ziemlich schnell veraltet.

• Cray- oder IBM-Supercomputer: MPI wird automatisch auf diesen Computern installiert und basiert in beiden Fällen auf MPICH. Es gab Demonstrationen von MPICH auf Cray XC40 ( hier ) mit OFI , Intel MPI auf Cray XC40 ( hier ) mit OFI, MPICH auf Blue Gene / Q mit OFI ( hier ) und Open-MPI auf Cray XC40 mit OFI und uGNI ( hier ), aber keine davon wird vom Hersteller unterstützt.

• Windows: Ich sehe keinen Sinn darin, MPI unter Windows auszuführen, außer über eine Linux-VM, aber sowohl Microsoft MPI als auch Intel MPI unterstützen Windows und sind MPICH-basiert. Ich habe Berichte über erfolgreiche Builds von MPICH oder Open-MPI unter Windows Subsystem für Linux gehört , habe aber keine persönlichen Erfahrungen.

Anmerkungen

Bei vollständiger Offenlegung arbeite ich derzeit für Intel in einer Forschungs- / Pfadfindungsfunktion (dh ich arbeite nicht an Intel-Softwareprodukten) und arbeitete zuvor fünf Jahre für Argonne National Lab, wo ich intensiv mit dem MPICH-Team zusammengearbeitet habe.

Wenn Sie eher Entwicklung als Produktionssystem betreiben, entscheiden Sie sich für MPICH. MPICH hat einen eingebauten Debugger, während Open-MPI nicht das letzte Mal überprüft hat.

In der Produktion wird Open-MPI höchstwahrscheinlich schneller sein. Dann möchten Sie vielleicht nach anderen Alternativen suchen, z. B. nach Intel MPI.

Ich stimme dem vorherigen Poster zu. Versuchen Sie beide, um festzustellen, auf welcher Ihre Anwendung schneller ausgeführt wird, und verwenden Sie sie dann für die Produktion. Sie sind beide standardkonform. Wenn es Ihr Desktop ist, ist beides in Ordnung. OpenMPI ist auf Macbooks sofort einsatzbereit, und MPICH scheint Linux / Valgrind-freundlicher zu sein. Es ist zwischen Ihnen und Ihrer Toolchain.

Wenn es sich um einen Produktionscluster handelt, müssen Sie ein umfassenderes Benchmarking durchführen, um sicherzustellen, dass es für Ihre Netzwerktopologie optimiert ist. Die Konfiguration in einem Produktionscluster ist der Hauptunterschied in Bezug auf Ihre Zeit, da Sie RTFM benötigen.

Beide sind standardkonform, daher sollte es aus Sicht der Korrektheit keine Rolle spielen, welche Sie verwenden. Wenn Sie keine Funktion wie bestimmte Debug-Erweiterungen benötigen, vergleichen Sie beide und wählen Sie die für Ihre Apps auf Ihrer Hardware schnellere aus. Bedenken Sie auch, dass es andere MPI-Implementierungen gibt, die möglicherweise eine bessere Leistung oder Kompatibilität bieten, z. B. MVAPICH (kann die beste InfiniBand-Leistung aufweisen) oder Intel MPI (weit verbreitete ISVs). HP hat hart daran gearbeitet, sein MPI mit vielen ISV-Codes zu qualifizieren, aber ich bin mir nicht sicher, wie es nach dem Verkauf an Platform läuft ...

Nach meiner Erfahrung ist eine gute Funktion, die OpenMPI unterstützt, MPICH jedoch nicht, die Prozessaffinität . In OpenMPI können -npersocketSie beispielsweise mit festlegen, wie viele Ränge an jedem Socket gestartet werden sollen. OpenMPIs rankfilesind auch sehr praktisch, wenn Sie Ränge für Kerne genau bestimmen oder sie überzeichnen möchten.

Wenn Sie die Zuordnung von Rängen zu Kernen steuern müssen, würde ich definitiv empfehlen, Ihren Code mit OpenMPI zu schreiben und zu kompilieren.