MPICH vs OpenMPI
Quelqu'un peut-il préciser les différences entre les implémentations OpenMPI et MPICH de MPI? Lequel des deux est une meilleure implémentation?
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é conforme à la dernière norme MPI) et constitue la base des implémentations de produits dérivés pour répondre à des besoins spécifiques. Open-MPI cible le cas courant, à la fois en termes d'utilisation et conduits de réseau.
Prise en charge de la technologie de réseau
Open-MPI documente son support réseau ici . MPICH répertorie ces informations dans le README distribué avec chaque version (par exemple this est pour 3.2.1). Notez que, comme Open-MPI et MPICH prennent en charge le - OFI (couche libfabric), ils supportent de nombreux réseaux identiques. Cependant, libfabric est une API multi-facettes, il est donc possible que tous les réseaux ne soient pas supportés 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 connais pas de prise en charge équivalente dans Open-MPI). Toutefois, les implémentations basées sur OFI de MPICH et d'Open-MPI travaillent sur des Mémoire, 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.-à-d. sans OFI au milieu).
Dans le passé, MPICH se plaignait souvent de ne pas prendre 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 on veut définir MPICH comme "MPICH et ses dérivés", MPICH a alors Prise en charge réseau étendue, comprenant à la fois des interconnexions InfiniBand et propriétaires telles que 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. Plus récemment, MPICH a pris en charge InfiniBand via un netmod (maintenant obsolète), mais MVAPICH2 dispose de nombreuses optimisations qui en font l’implémentation préférée dans presque tous les cas.
Prise en charge de la dernière norme MPI Standard
La couverture du standard MPI) est un axe orthogonal au support matériel/plate-forme. MPICH est généralement de loin supérieur. MPICH a été la première implémentation de chaque version de MPI standard, de MPI-1 à MPI-3 Open-MPI a récemment pris en charge MPI-3 et j’ai constaté que certaines fonctionnalités de MPI-3 présentaient des erreurs sur certaines plates-formes (MPICH n’est pas exempt de bogues, bien sûr). , mais les bugs dans les fonctionnalités de MPI-3 étaient beaucoup moins courants).
Historiquement, Open-MPI n’avait pas de support global pour MPI_THREAD_MULTIPLE, qui est critique 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 a bénéficié d'un soutien global pour MPI_THREAD_MULTIPLE pendant de nombreuses années, même si l’implémentation n’est pas toujours très performante (voir "Verrouillage des aspects dans le traitement multithread MPI Implémentations" pour une analyse).
Une autre fonctionnalité cassée dans Open-MPI 1.x était la communication unilatérale, également appelée RMA. Ceci a été corrigé plus récemment et je constate, en tant qu'utilisateur très expérimenté de ces fonctionnalités, qu'elles fonctionnent généralement bien dans Open-MPI 3.x (voir par exemple le matrice de test ARMCI-MPI dans Travis CI = pour les résultats montrant que RMA fonctionne avec les deux implémentations, du 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
Le gestionnaire de processus était un domaine dans lequel Open-MPI était nettement supérieur. L'ancien lancement de MPICH (MPD) était fragile et difficile à utiliser. Heureusement, il est obsolète depuis de nombreuses années (voir le MPICH FAQ entrée pour plus de détails).) Ainsi, les critiques formulées à l'encontre de MPICH à cause de MPD sont fausses.
Le gestionnaire de processus Hydra est très 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. Selon certaines sources, le lancement des processus Open-MPI serait plus rapide que les dérivés de MPICH pour les travaux plus importants (plus de 1 000 processus), mais comme je n'ai pas l'expérience de première main ici, je ne suis pas à l'aise pour en tirer des conclusions. De tels problèmes de performances sont généralement spécifiques au réseau et parfois même à la machine.
J'ai trouvé Open-MPI 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 pourrait disparaître à l’avenir.
Portabilité binaire
Alors que MPICH et Open-MPI sont des logiciels à code source ouvert pouvant être compilés sur un large éventail de plates-formes, la portabilité des bibliothèques MPI sous forme binaire, ou des programmes liés à ces bibliothèques) est souvent importante. .
MPICH et beaucoup de ses dérivés supportent la compatibilité ABI ( website ), ce qui signifie que l'interface binaire de la bibliothèque est constante et que l'on peut donc compiler avec mpi.h d'une implémentation, puis exécuté avec une autre. Cela est vrai même à travers plusieurs versions des bibliothèques. Par exemple, je compile fréquemment Intel MPI mais LD_PRELOAD une version de développement de MPICH au moment de l'exécution. L'un des gros avantages de la compatibilité ABI est que les éditeurs de logiciels indépendants peuvent publier des fichiers binaires compilés avec 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 mpirun ou mpiexec, avec ses démons de noeud de calcul)) et = MPI bibliothèque partout. Ce n'est pas nécessairement le cas pour les conteneurs.
Bien qu'Open-MPI ne promette pas la compatibilité ABI, ils ont fortement investi dans la prise en charge des conteneurs ( docs , slides ). Cela nécessite un soin particulier pour maintenir la compatibilité entre les différentes versions des MPI launcher, des démons de launcher et de la MPI Bibliothèque, car un utilisateur peut lancer des travaux avec une version plus récente). du lanceur MPI plus que les démons du lanceur dans le support de conteneur. Sans prêter une attention particulière à la stabilité de l'interface du lanceur, les jobs de conteneur ne se lanceront que si les versions de chaque composant du lanceur sont compatibles. Ce n'est pas le cas. 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 avoir des opérations d'infrastructure entre versions.
Je remercie Ralph Castain de l'équipe Open-MPI de m'avoir expliqué les problèmes liés aux conteneurs. La citation qui précède est la sienne.
Comparaison par 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 auprès de Homebrew. Il n'y a aucune raison de penser aux performances de MPI si vous utilisez un ordinateur portable Mac).
Linux avec mémoire partagée: Open-MPI et MPICH devraient fonctionner correctement. Si vous souhaitez une version prenant en charge 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 au courant d'aucune différence de performance significative entre les deux implémentations. Les deux prennent en charge les optimisations en copie unique si le système d'exploitation les permet.
Linux avec Mellanox InfiniBand: utilisez Open-MPI ou MVAPICH2. Si vous voulez une version qui supporte tout MPI-3 ou
MPI_THREAD_MULTIPLE, vous aurez probablement besoin de MVAPICH2. Je trouve que MVAPICH2 fonctionne très bien, mais n’a pas fait de comparaison directe avec OpenMPI sur InfiniBand, en partie parce que les fonctionnalités pour lesquelles la performance compte le plus pour moi (RMA, dit unilatéral) ont déjà été dépassées dans Open-MPI.Linux avec Intel Omni Path (ou son prédécesseur, True Scale): j’utilise MVAPICH2, Intel MPI, MPICH et Open-MPI sur de tels systèmes, et ils fonctionnent tous. Intel MPI a tendance à être optimisé, alors que Open-MPI offre les meilleures performances des implémentations open-source, car elles ont un back-end bien optimisé PSM2 - .J'ai quelques notes sur GitHub sur la façon de construire différentes implémentations open-source, mais de telles informations deviennent obsolètes assez rapidement.
Cray ou les superordinateurs IBM: MPI est installé automatiquement sur ces machines 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 bleu Gene/Q utilisant OFI ( ici ) et Open-MPI sur Cray XC40 utilisant à la fois OFI et uGNI ( ici ), mais aucun de ceux-ci n'est pris en charge par le fournisseur.
Windows: je ne vois pas l'intérêt d'exécuter MPI sous Windows, sauf via une machine virtuelle Linux, mais les deux Microsoft MPI et Intel MPI = supporte Windows et est basé sur MPICH. J'ai entendu parler de versions réussies de MPICH ou d'Open-MPI utilisant Windows Subsystem for Linux mais je n'ai aucune expérience personnelle.
Remarques
En toute transparence, je travaille actuellement pour Intel dans le domaine de la recherche et du développement (c’est-à-dire que je ne travaille sur aucun produit logiciel Intel). J’avais travaillé pendant cinq ans pour Argonne National Lab, où j’ai beaucoup collaboré avec l’équipe de MPICH.
Si vous faites du développement plutôt que du système de production, utilisez MPICH. MPICH a un débogueur intégré, alors qu'Open-MPI ne vérifie pas la dernière fois.
En production, Open-MPI sera probablement plus rapide. Mais alors, vous voudrez peut-être rechercher d’autres solutions, telles que Intel MPI.
Je suis d'accord avec l'affiche précédente. Essayez les deux pour voir celle sur laquelle votre application s'exécute plus rapidement puis utilisez-la pour la production. Ils sont tous deux conformes aux normes. Si c'est votre bureau, ça va. OpenMPI sort des sentiers battus sur les Macbooks, et MPICH semble être plus compatible avec Linux/Valgrind. C'est entre vous et votre chaîne d'outils.
S'il s'agit d'un cluster de production, vous devez effectuer une analyse comparative plus approfondie pour vous assurer qu'il est optimisé pour la topologie de votre réseau. La configuration sur un cluster de production sera la principale différence en termes de temps car vous devrez RTFM.
Les deux sont conformes aux normes, vous ne devez donc pas importer ce que vous utilisez du point de vue de l'exactitude. Si vous avez besoin d'une fonctionnalité, telle que des extensions de débogage spécifiques, telles que des extensions de débogage, effectuez un test de performances et sélectionnez le choix le plus rapide pour vos applications sur votre matériel. Considérez également qu’il existe d’autres MPI implémentations qui pourraient améliorer les performances ou la compatibilité, telles que MVAPICH (peut offrir les meilleures performances InfiniBand) ou Intel MPI (généralement pris en charge. HP a travaillé dur pour obtenir leur MPI qualifié avec de nombreux codes ISV aussi, mais je ne suis pas sûr de son évolution après avoir été vendu à Platform ...
D'après mon expérience, une bonne fonctionnalité qu'OpenMPI prend en charge, mais pas MPICH, est affinité de processus. Par exemple, dans OpenMPI, utilisez -npersocket vous pouvez définir le nombre de rangs lancés sur chaque socket. En outre, rankfile d'OpenMPI est très pratique lorsque vous souhaitez localiser des rangs sur des cœurs ou les sursouscrire.
Enfin, si vous avez besoin de contrôler le mappage des rangs sur les cœurs, je suggérerais certainement d'écrire et de compiler votre code avec OpenMPI.