Objectif
Premièrement, il est important de reconnaître en quoi MPICH et Open-MPI sont différents, c'est-à-dire qu'ils sont conçus pour répondre à des besoins différents. MPICH est censé être une implémentation de référence de haute qualité de la dernière norme MPI et la base des implémentations dérivées pour répondre à des besoins spécifiques. Open-MPI cible le cas commun, à la fois en termes d'utilisation et de conduits réseau.
Prise en charge de la technologie réseau
Open-MPI documente leur support réseau ici . MPICH énumère ces informations dans le fichier README distribué avec chaque version (par exemple , c'est pour 3.2.1). Notez que parce que Open-MPI et MPICH prennent en charge l' OFI(aka libfabric) couche réseau, ils prennent en charge plusieurs des mêmes réseaux. Cependant, libfabric est une API à multiples facettes, donc tous les réseaux ne peuvent pas être pris en charge de la même manière dans les deux (par exemple, MPICH a une implémentation IBM Blue Gene / Q basée sur OFI, mais je ne suis pas au courant d'un support équivalent dans Open-MPI) . Cependant, les implémentations basées sur OFI de MPICH et d'Open-MPI fonctionnent sur la mémoire partagée, Ethernet (via TCP / IP), Mellanox InfiniBand, Intel Omni Path et probablement d'autres réseaux. Open-MPI prend également en charge ces deux réseaux et d'autres en mode natif (c'est-à-dire sans OFI au milieu).
Dans le passé, une plainte courante à propos de MPICH est qu'il ne prend pas en charge InfiniBand, contrairement à Open-MPI. Cependant, MVAPICH et Intel MPI (entre autres) - qui sont tous deux des dérivés de MPICH - prennent en charge InfiniBand, donc si l'on est prêt à définir MPICH comme «MPICH et ses dérivés», alors MPICH dispose d'un support réseau extrêmement large, comprenant à la fois InfiniBand et propriétaire. interconnexions comme Cray Seastar, Gemini et Aries ainsi que IBM Blue Gene (/ L, / P et / Q). Open-MPI prend également en charge l'interconnexion Cray Gemini, mais son utilisation n'est pas prise en charge par Cray. Plus récemment, MPICH a pris en charge InfiniBand via un netmod (désormais obsolète), mais MVAPICH2 a des optimisations étendues qui en font l'implémentation préférée dans presque tous les cas.
Prise en charge des fonctionnalités de la dernière norme MPI
Un axe orthogonal au support matériel / plate-forme est la couverture de la norme MPI. Ici, MPICH est généralement de loin supérieur. MPICH a été la première implémentation de chaque version de la norme MPI, de MPI-1 à MPI-3. Open-MPI n'a pris en charge MPI-3 que récemment et je trouve que certaines fonctionnalités MPI-3 sont boguées sur certaines plates-formes (MPICH n'est pas exempt de bogues, bien sûr, mais les bogues dans les fonctionnalités MPI-3 ont été beaucoup moins courants).
Historiquement, Open-MPI n'a pas eu de support holistique pour MPI_THREAD_MULTIPLE, ce qui est essentiel pour certaines applications. Il peut être pris en charge sur certaines plates-formes mais ne peut généralement pas être supposé fonctionner. D'autre part, MPICH bénéficie d'un support global depuis MPI_THREAD_MULTIPLEde nombreuses années, bien que l'implémentation ne soit pas toujours performante (voir «Verrouillage des aspects dans les implémentations MPI multithread» pour une analyse).
Une autre fonctionnalité qui a été cassée dans Open-MPI 1.x était la communication unilatérale, alias RMA. Cela a été corrigé plus récemment et je trouve, en tant qu'utilisateur très intensif de ces fonctionnalités, qu'elles fonctionnent généralement bien dans Open-MPI 3.x (voir par exemple la matrice de test ARMCI-MPI dans Travis CI pour les résultats montrant RMA fonctionnant avec les deux implémentations, au moins en mémoire partagée.J'ai vu des résultats positifs similaires sur Intel Omni Path, mais je n'ai pas testé Mellanox InfiniBand.
La gestion des processus
Un domaine où Open-MPI était autrefois nettement supérieur était le gestionnaire de processus. L'ancien lancement MPICH (MPD) était fragile et difficile à utiliser. Heureusement, il est obsolète depuis de nombreuses années (voir l' entrée FAQ MPICH pour plus de détails). Ainsi, la critique de MPICH en raison de MPD est fallacieuse.
Le gestionnaire de processus Hydra est assez bon et a la même convivialité et les mêmes fonctionnalités que ORTE (dans Open-MPI), par exemple, les deux prennent en charge HWLOC pour le contrôle de la topologie des processus. Il y a des rapports selon lesquels le lancement de processus Open-MPI est plus rapide que les dérivés MPICH pour des travaux plus importants (plus de 1000 processus), mais comme je n'ai pas d'expérience de première main ici, je ne suis pas à l'aise pour énoncer des conclusions. Ces problèmes de performances sont généralement spécifiques au réseau et parfois même spécifiques à la machine.
J'ai trouvé qu'Open-MPI est plus robuste lors de l'utilisation de MacOS avec un VPN, c'est-à-dire que MPICH peut se bloquer au démarrage en raison de problèmes de résolution de nom d'hôte. Comme il s'agit d'un bogue, ce problème peut disparaître à l'avenir.
Portabilité binaire
Alors que MPICH et Open-MPI sont tous deux des logiciels open source qui peuvent être compilés sur un large éventail de plates-formes, la portabilité des bibliothèques MPI sous forme binaire ou des programmes liés à celles-ci est souvent importante.
MPICH et beaucoup de ses dérivés prennent en charge la compatibilité ABI ( site Web ), ce qui signifie que l'interface binaire vers la bibliothèque est constante et que par conséquent, on peut compiler avec à mpi.hpartir d'une implémentation puis exécuter avec une autre. Cela est vrai même dans plusieurs versions des bibliothèques. Par exemple, je compile fréquemment Intel MPI mais LD_PRELOADune version de développement de MPICH au moment de l'exécution. L'un des grands avantages de la compatibilité ABI est que les ISV (Independent Software Vendors) peuvent publier des binaires compilés contre un seul membre de la famille MPICH.
ABI n'est pas le seul type de compatibilité binaire. Les scénarios décrits ci-dessus supposent que les utilisateurs utilisent la même version du lanceur MPI (généralement mpirunou mpiexec, avec ses démons de nœud de calcul) et la bibliothèque MPI partout. Ce n'est pas nécessairement le cas pour les conteneurs.
Bien qu'Open-MPI ne promette pas la compatibilité ABI, ils ont beaucoup investi dans la prise en charge des conteneurs ( documents , diapositives ). Cela nécessite une grande attention pour maintenir la compatibilité entre les différentes versions du lanceur MPI, des démons du lanceur et de la bibliothèque MPI, car un utilisateur peut lancer des travaux en utilisant une version plus récente du lanceur MPI que les démons du lanceur dans le support du conteneur. Sans une attention particulière à la stabilité de l'interface du lanceur, les travaux de conteneur ne seront lancés que si les versions de chaque composant du lanceur sont compatibles. Ce n'est pas un problème insurmontable:
La solution de contournement utilisée par le monde Docker, par exemple, consiste à conteneuriser l'infrastructure avec l'application. En d'autres termes, vous incluez le démon MPI dans le conteneur avec l'application elle-même, puis vous exigez que tous les conteneurs (mpiexec inclus) soient de la même version. Cela évite le problème car vous n'avez plus d'opérations d'infrastructure multi-versions.
Je remercie Ralph Castain de l'équipe Open-MPI de m'avoir expliqué les problèmes liés aux conteneurs. La citation immédiatement précédente est la sienne.
Comparaison spécifique à la plate-forme
Voici mon évaluation plateforme par plateforme:
Mac OS: Open-MPI et MPICH devraient fonctionner correctement. Pour bénéficier des dernières fonctionnalités de la norme MPI-3, vous devez utiliser une version récente d'Open-MPI, disponible sur Homebrew. Il n'y a aucune raison de penser aux performances MPI si vous utilisez un ordinateur portable Mac.
Linux avec mémoire partagée: Open-MPI et MPICH devraient fonctionner correctement. Si vous voulez une version qui prend en charge tous les MPI-3 ou MPI_THREAD_MULTIPLE, vous aurez probablement besoin de MPICH, à moins que vous ne construisiez Open-MPI vous-même, car par exemple Ubuntu 16.04 ne fournit que l'ancienne version 1.10 via APT. Je ne suis pas au courant de différences de performances significatives entre les deux implémentations. Les deux prennent en charge les optimisations à copie unique si le système d'exploitation les autorise.
Linux avec Mellanox InfiniBand: utilisez Open-MPI ou MVAPICH2. Si vous voulez une version qui prend en charge tous MPI-3 ou MPI_THREAD_MULTIPLE, vous aurez probablement besoin de MVAPICH2. Je trouve que MVAPICH2 fonctionne très bien mais je n'ai pas fait de comparaison directe avec OpenMPI sur InfiniBand, en partie parce que les fonctionnalités pour lesquelles les performances comptent le plus pour moi (RMA aka unilatéral) ont été cassées dans Open-MPI dans le passé.
Linux avec Intel Omni Path (ou son prédécesseur, True Scale): J'ai utilisé MVAPICH2, Intel MPI, MPICH et Open-MPI sur de tels systèmes, et tous fonctionnent. Intel MPI a tendance à être le plus optimisé tandis qu'Open-MPI a fourni les meilleures performances des implémentations open-source car elles ont un back-end basé sur PSM2 bien optimisé . J'ai quelques notes sur GitHub sur la façon de construire différentes implémentations open source, mais ces informations deviennent obsolètes assez rapidement.
Supercalculateurs Cray ou IBM: MPI est installé sur ces machines automatiquement et il est basé sur MPICH dans les deux cas. Il y a eu des démonstrations de MPICH sur Cray XC40 ( ici ) en utilisant OFI , Intel MPI sur Cray XC40 ( ici ) en utilisant OFI, MPICH sur Blue Gene / Q en utilisant OFI ( ici ) et Open-MPI sur Cray XC40 en utilisant à la fois OFI et uGNI ( ici ), mais aucun de ceux-ci n'est pris en charge par le fournisseur.
Windows: Je ne vois aucun intérêt à exécuter MPI sur Windows sauf via une machine virtuelle Linux, mais Microsoft MPI et Intel MPI prennent en charge Windows et sont basés sur MPICH. J'ai entendu des rapports de versions réussies de MPICH ou d'Open-MPI utilisant le sous-système Windows pour Linux mais je n'ai aucune expérience personnelle.
Remarques
En pleine divulgation, je travaille actuellement pour Intel dans une capacité de recherche / orientation (c'est-à-dire que je ne travaille sur aucun produit logiciel Intel) et j'ai travaillé auparavant pour Argonne National Lab pendant cinq ans, où j'ai beaucoup collaboré avec l'équipe MPICH.