Qualcuno può elaborare le differenze tra le implementazioni OpenMPI e MPICH di MPI? Quale dei due è una migliore implementazione?

Scopo

Innanzitutto, è importante riconoscere in che modo MPICH e Open-MPI sono diversi, ovvero che sono progettati per soddisfare esigenze diverse. Si suppone che MPICH sia un'implementazione di riferimento di alta qualità dell'ultimo standard MPI e la base per implementazioni derivate per soddisfare esigenze con scopi speciali. Open-MPI si rivolge al caso comune, sia in termini di utilizzo che di condotte di rete.

Supporto per la tecnologia di rete

Open-MPI documenta il loro supporto di rete qui . MPICH elenca queste informazioni nel file README distribuito con ciascuna versione (ad esempio, questo è per 3.2.1). Si noti che poiché Open-MPI e MPICH supportano OFI(aka libfabric) livello di rete, supportano molte delle stesse reti. Tuttavia, libfabric è un'API multiforme, quindi non tutte le reti possono essere supportate allo stesso modo in entrambi (ad esempio MPICH ha un'implementazione IBM Blue Gene / Q basata su OFI, ma non sono a conoscenza del supporto equivalente in Open-MPI) . Tuttavia, le implementazioni basate su OFI di MPICH e Open-MPI stanno lavorando su memoria condivisa, Ethernet (via TCP / IP), Mellanox InfiniBand, Intel Omni Path e probabilmente altre reti. Open-MPI supporta anche entrambe queste reti e altre nativamente (cioè senza OFI nel mezzo).

In passato, una lamentela comune su MPICH è che non supporta InfiniBand, mentre Open-MPI non lo supporta. Tuttavia, MVAPICH e Intel MPI (tra gli altri) - entrambi i quali sono derivati ​​MPICH - supportano InfiniBand, quindi se uno è disposto a definire MPICH come "MPICH e suoi derivati", allora MPICH ha un supporto di rete estremamente ampio, inclusi InfiniBand e proprietari interconnessioni come Cray Seastar, Gemini e Aries nonché IBM Blue Gene (/ L, / P e / Q). Open-MPI supporta anche l'interconnessione Cray Gemini, ma il suo utilizzo non è supportato da Cray. Più recentemente, MPICH ha supportato InfiniBand attraverso un netmod (ora deprecato), ma MVAPICH2 ha ampie ottimizzazioni che lo rendono l'implementazione preferita in quasi tutti i casi.

Supporto delle funzionalità secondo l'ultimo standard MPI

Un asse ortogonale al supporto hardware / piattaforma è la copertura dello standard MPI. Qui MPICH è di solito di gran lunga superiore. MPICH è stata la prima implementazione di ogni singola versione dello standard MPI, da MPI-1 a MPI-3. Open-MPI ha solo recentemente supportato MPI-3 e trovo che alcune funzionalità MPI-3 siano buggy su alcune piattaforme (MPICH non è privo di bug, ovviamente, ma i bug nelle funzionalità MPI-3 sono stati molto meno comuni).

Storicamente, Open-MPI non ha avuto il supporto olistico MPI_THREAD_MULTIPLE, il che è fondamentale per alcune applicazioni. Potrebbe essere supportato su alcune piattaforme ma generalmente non si può presumere che funzioni. D'altro canto, MPICH ha avuto un supporto olistico MPI_THREAD_MULTIPLEper molti anni, sebbene l'implementazione non sia sempre ad alte prestazioni (vedere "Blocco degli aspetti nelle implementazioni MPI multithread" per un'analisi).

Un'altra caratteristica che era stata interrotta in Open-MPI 1.x era la comunicazione unilaterale, nota anche come RMA. Questo è stato risolto più di recente e trovo, come utente molto pesante di queste funzionalità, che generalmente funzionano bene in Open-MPI 3.x (vedi ad esempio la matrice di test ARMCI-MPI in Travis CI per i risultati che mostrano che RMA funziona con entrambe le implementazioni, almeno nella memoria condivisa. Ho visto risultati positivi simili su Intel Omni Path, ma non ho testato Mellanox InfiniBand.

Gestione dei processi

Un'area in cui Open-MPI era significativamente superiore era il gestore dei processi. Il vecchio lancio di MPICH (MPD) era fragile e difficile da usare. Fortunatamente, è stato deprecato per molti anni (vedi la voce FAQ MPICH per i dettagli). Pertanto, le critiche a MPICH a causa di MPD sono false.

Il gestore di processi Hydra è abbastanza buono e ha la stessa usabilità e funzionalità simili a ORTE (in Open-MPI), ad esempio entrambi supportano HWLOC per il controllo della topologia di processo. Ci sono notizie che l'avvio del processo Open-MPI sia più veloce rispetto ai derivati ​​MPICH per lavori di grandi dimensioni (oltre 1000 processi), ma poiché non ho esperienza diretta qui, non mi sento a mio agio nel dichiarare delle conclusioni. Tali problemi di prestazioni sono generalmente specifici della rete e talvolta persino specifici della macchina.

Ho trovato Open-MPI più robusto quando si utilizza MacOS con una VPN, vale a dire che MPICH potrebbe bloccarsi all'avvio a causa di problemi di risoluzione del nome host. Poiché si tratta di un bug, questo problema potrebbe scomparire in futuro.

Portabilità binaria

Mentre sia MPICH che Open-MPI sono software open source che possono essere compilati su una vasta gamma di piattaforme, la portabilità delle librerie MPI in forma binaria o programmi collegati contro di esse, è spesso importante.

MPICH e molti dei suoi derivati ​​supportano la compatibilità ABI ( sito Web ), il che significa che l'interfaccia binaria con la libreria è costante e quindi si può compilare mpi.hda un'implementazione e quindi eseguirla con un'altra. Questo è vero anche su più versioni delle librerie. Ad esempio, compilo spesso Intel MPI ma LD_PRELOADuna versione di sviluppo di MPICH in fase di esecuzione. Uno dei grandi vantaggi della compatibilità ABI è che gli ISV (Independent Software Vendor) possono rilasciare binari compilati su un solo membro della famiglia MPICH.

ABI non è l'unico tipo di compatibilità binaria. Gli scenari sopra descritti presuppongono che gli utenti utilizzino la stessa versione del launcher MPI (di solito mpiruno mpiexec, insieme ai suoi demoni nodo di calcolo) e la libreria MPI ovunque. Questo non è necessariamente il caso dei contenitori.

Sebbene Open-MPI non prometta la compatibilità ABI, hanno investito molto in contenitori di supporto ( documenti , diapositive ). Ciò richiede grande cura nel mantenere la compatibilità tra le diverse versioni del programma di avvio MPI, dei daemon di avvio e della Libreria MPI, poiché un utente può avviare processi utilizzando una versione più recente del programma di avvio MPI rispetto ai daemon di avvio nel supporto contenitore. Senza un'attenta attenzione alla stabilità dell'interfaccia del programma di avvio, i processi contenitore non verranno avviati a meno che le versioni di ciascun componente del programma di avvio non siano compatibili. Questo non è un problema insormontabile:

La soluzione alternativa utilizzata dal mondo Docker, ad esempio, consiste nel containerizzare l'infrastruttura insieme all'applicazione. In altre parole, includi il demone MPI nel contenitore con l'applicazione stessa e quindi richiedi che tutti i contenitori (incluso mpiexec) siano della stessa versione. Ciò evita il problema in quanto non si hanno più operazioni infrastrutturali tra versioni.

Riconosco Ralph Castain del team Open-MPI per avermi spiegato le problematiche relative al container. La citazione immediatamente precedente è sua.

Confronto specifico della piattaforma

Ecco la mia valutazione su una piattaforma per piattaforma:

• Mac OS: sia Open-MPI che MPICH dovrebbero funzionare bene. Per ottenere le ultime funzionalità dello standard MPI-3, è necessario utilizzare una versione recente di Open-MPI, disponibile da Homebrew. Non c'è motivo di pensare alle prestazioni MPI se si esegue su un laptop Mac.

• Linux con memoria condivisa: sia Open-MPI che MPICH dovrebbero funzionare bene. Se vuoi una versione di rilascio che supporti tutti MPI-3 o MPI_THREAD_MULTIPLE, probabilmente avrai bisogno di MPICH, a meno che tu non costruisca Open-MPI da solo, perché ad esempio Ubuntu 16.04 fornisce solo la versione antica 1.10 tramite APT. Non sono a conoscenza di differenze significative nelle prestazioni tra le due implementazioni. Entrambi supportano ottimizzazioni a copia singola se il sistema operativo lo consente.

• Linux con Mellanox InfiniBand: utilizzare Open-MPI o MVAPICH2. Se si desidera una versione di rilascio che supporti tutto MPI-3 o MPI_THREAD_MULTIPLE, probabilmente è necessario MVAPICH2. Trovo che MVAPICH2 funzioni molto bene, ma non ho fatto un confronto diretto con OpenMPI su InfiniBand, in parte perché le funzionalità per le quali le prestazioni contano di più per me (RMA aka unilaterale) sono state interrotte in Open-MPI in passato.

• Linux con Intel Omni Path (o il suo predecessore, True Scale): ho usato MVAPICH2, Intel MPI, MPICH e Open-MPI su tali sistemi e tutti funzionano. Intel MPI tende al più ottimizzato mentre Open-MPI offre le migliori prestazioni delle implementazioni open source perché hanno un back-end ben ottimizzato basato su PSM2 . Ho alcune note su GitHub su come costruire diverse implementazioni open source, ma tali informazioni diventano obsolete piuttosto rapidamente.

• Supercomputer Cray o IBM: MPI viene installato automaticamente su queste macchine e si basa su MPICH in entrambi i casi. Ci sono state dimostrazioni di MPICH su Cray XC40 ( qui ) usando OFI , Intel MPI su Cray XC40 ( qui ) usando OFI, MPICH su Blue Gene / Q usando OFI ( qui ) e Open-MPI su Cray XC40 usando sia OFI che uGNI ( qui ), ma nessuno di questi è supportato dal fornitore.

• Windows: non vedo il punto di eseguire MPI su Windows se non tramite una VM Linux, ma sia Microsoft MPI che Intel MPI supportano Windows e sono basate su MPICH. Ho sentito notizie di build di successo di MPICH o Open-MPI usando il sottosistema Windows per Linux ma non ho esperienza personale.

Appunti

In piena divulgazione, attualmente lavoro per Intel in una ricerca / capacità di ricerca di percorsi (cioè non lavoro su alcun prodotto software Intel) e precedentemente ho lavorato per Argonne National Lab per cinque anni, dove ho collaborato ampiamente con il team MPICH.

Se fai lo sviluppo piuttosto che il sistema di produzione, vai con MPICH. MPICH ha il debugger integrato, mentre Open-MPI non è l'ultima volta che ho controllato.

In produzione, Open-MPI molto probabilmente sarà più veloce. Ma allora potresti voler cercare altre alternative, come Intel MPI.

Concordo con il poster precedente. Prova entrambi per vedere su quale applicazione viene eseguita più velocemente, quindi utilizzala per la produzione. Sono entrambi conformi agli standard. Se è il desktop va bene lo stesso. OpenMPI è pronto all'uso su Macbook e MPICH sembra essere più compatibile con Linux / Valgrind. È tra te e la tua toolchain.

Se si tratta di un cluster di produzione, è necessario eseguire benchmark più estesi per assicurarsi che sia ottimizzato per la topologia di rete. Configurarlo su un cluster di produzione sarà la differenza principale in termini di tempo, poiché dovrai RTFM.

Entrambi sono conformi agli standard, quindi non dovrebbe importare quale si utilizza dal punto di vista della correttezza. A meno che non ci siano alcune funzionalità, come specifiche estensioni di debug, di cui hai bisogno, quindi esegui un benchmark di entrambi e scegli quale è più veloce per le tue app sul tuo hardware. Considera anche che ci sono altre implementazioni MPI che potrebbero fornire migliori prestazioni o compatibilità, come MVAPICH (può avere le migliori prestazioni InfiniBand) o Intel MPI (ISV ampiamente supportati). HP ha lavorato duramente per ottenere la qualifica MPI anche con molti codici ISV, ma non sono sicuro di come stia andando dopo essere stato venduto sulla piattaforma ...

Dalla mia esperienza, una buona funzionalità supportata da OpenMPI ma MPICH non è l' affinità di processo . Ad esempio, in OpenMPI, utilizzando -npersocketè possibile impostare il numero di ranghi lanciati su ciascun socket. Inoltre, OpenMPI rankfileè abbastanza utile quando si desidera individuare i ranghi in core o sovrascriverli.

Infine, se hai bisogno di controllare la mappatura dei ranghi sui core, suggerirei sicuramente di scrivere e compilare il tuo codice usando OpenMPI.