Quelle est la meilleure implémentation de MPI [fermé]

Question

Je dois implémenter le système MPI dans un cluster. Si quelqu'un ici a une expérience avec MPI (MPICH / OpenMPI), j'aimerais savoir lequel est le meilleur et comment les performances peuvent être améliorées sur un cluster de boîtes x86_64.

Answer 1

MPICH existe depuis beaucoup plus longtemps. Il est extrêmement portable et vous trouverez des années de trucs et astuces en ligne. C’est une valeur sûre et probablement compatible avec davantage de programmes MPI.

OpenMPI est plus récent. Bien que ce ne soit pas aussi portable, il supporte très bien les plateformes les plus courantes. La plupart des gens semblent penser que la situation est bien meilleure à plusieurs égards, notamment en ce qui concerne la tolérance aux pannes - mais pour en tirer parti, vous devrez peut-être utiliser certaines de ses fonctionnalités spéciales qui ne font pas partie du standard MPI.

En ce qui concerne les performances, cela dépend beaucoup de l’application. il est difficile de donner des conseils généraux. Vous devez poser une question spécifique sur le type de calcul que vous souhaitez exécuter, le nombre de nœuds et le type de matériel, y compris le type de matériel réseau utilisé.

Answer 2

J'ai écrit pas mal d'applications parallèles pour les clusters Windows et Linux, et je peux vous dire que pour le moment, MPICH2 est probablement le choix le plus sûr. Comme l’a dit l’autre intervenant, cette bibliothèque est très mature. En outre, la diffusion est largement prise en charge (via MPI_Bcast ). Maintenant, et en fait, MPICH2 a quelques fonctionnalités vraiment intéressantes comme disperser et rassembler .

OpenMPI gagne cependant du terrain. Penguin Computing (un grand fournisseur de clusters, et ils aiment Linux), a de très bons points de repère où OpenMPI bat MPICH2 haut la main dans certaines circonstances.

En ce qui concerne votre commentaire sur "l'amélioration des performances", le meilleur conseil que je puisse vous donner est de ne jamais envoyer plus de données que ce qui est absolument nécessaire si vous êtes lié à une entrée / sortie, et de ne jamais effectuer plus de travail que nécessaire si vous êtes connecté. CPU lié. Je suis tombé dans le piège d'optimiser le mauvais morceau de code plusieurs fois :) J'espère que vous ne suivrez pas mes traces!

Consultez les forums MPI - ils contiennent de bonnes informations sur les routines MPI , ainsi que Le site Beowulf propose de nombreuses questions intéressantes.

Answer 3

Il est difficile de définir «mieux». Il est possible de répondre à «plus rapidement» en le comparant avec votre code et votre matériel. Des choses comme collective & amp; L’optimisation du déchargement dépendra de votre matériel exact et est également assez variable en ce qui concerne les versions de pile de pilotes, Google devrait pouvoir vous trouver des combinaisons de travail.

En ce qui concerne l'optimisation, cela dépend un peu du code et un peu du matériel.

Votre code I / O est-il lié au stockage? Dans ce cas, quelque chose de mieux que NFS pourrait aider beaucoup, ou utiliser MPI I / O plutôt que des E / S parallèles naïves

Si vous êtes lié au réseau, examiner la localité de communication et le chevauchement des communications / calculs peuvent être utiles. La plupart des diverses implémentations MPI disposent d'options de réglage pour utiliser la mémoire partagée locale plutôt que le réseau pour les communications intranodes, ce qui peut réduire considérablement la charge du réseau pour certains codes.

La séparation du trafic I / O et MPI peut faire une grande différence sur certains clusters, en particulier pour les clusters Gigabit Ethernet.

Answer 4

Nous avons utilisé mpich simplement parce que cela semblait être le plus disponible et le mieux documenté, nous n’avons pas déployé beaucoup d’efforts pour tester des alternatives. MPICH dispose d'outils raisonnables pour le déploiement sur Windows.
Le principal problème de performances était que nous devions transmettre les mêmes données de base à tous les nœuds et que MPICH ne prend pas (ou ne prenait) pas en charge la diffusion. Le déploiement des données initiales était donc O (n)

.