Un programme OpenMP tu fais juste un
#pragma omp parallel for
(avec éventuellement quelques ajouts pour dire ce qui doit être privatisé, public, les chunks en termes d'itérations à faire, quelles variables servent à faire des réductions, etc), alors qu'un programme MPI doit explicitement déclarer toutes ses communications, et donc le programmeur effectue nécessairement bien plus de boulot à lui tout seul.
Le problème avec OpenMP, c'est qu'on a nécessairement une barrière implicite à la fin d'une section parallèle. On peut tenter de s'en dépatouiller en utilisant « nowait » comme mot-clef dans certains cas, mais cela ne fait que retarder le moment où il faudra synchroniser les accès.
Le problème avec MPI, c'est qu'en plus d'avoir à tout faire à la main, je ne connais pour le moment aucune implémentation qui soit thread-safe ET efficace.
À mon avis, il faut un peu plus chercher du côté d'OpenMP, et revenir à des bibliothèques de threads à deux niveaux (MxN), où on fixe des threads noyau sur les coeurs/processeurs, et où on spawne des threads utilisateur à chaque nouvelle section parallèle (ce qui permettrait peut-être de « coller » au modèle fork/join d'OpenMP, tout en ayant un overhead minimal, et en assurant une possibilité d'avoir des « sections parallèles récursives »).
MPI est super efficace, mais bien trop contraignant à mon goût.
[^] # Re: Le fortran
Posté par lasher . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 3.
#pragma omp parallel for
(avec éventuellement quelques ajouts pour dire ce qui doit être privatisé, public, les chunks en termes d'itérations à faire, quelles variables servent à faire des réductions, etc), alors qu'un programme MPI doit explicitement déclarer toutes ses communications, et donc le programmeur effectue nécessairement bien plus de boulot à lui tout seul.
Le problème avec OpenMP, c'est qu'on a nécessairement une barrière implicite à la fin d'une section parallèle. On peut tenter de s'en dépatouiller en utilisant « nowait » comme mot-clef dans certains cas, mais cela ne fait que retarder le moment où il faudra synchroniser les accès.
Le problème avec MPI, c'est qu'en plus d'avoir à tout faire à la main, je ne connais pour le moment aucune implémentation qui soit thread-safe ET efficace.
À mon avis, il faut un peu plus chercher du côté d'OpenMP, et revenir à des bibliothèques de threads à deux niveaux (MxN), où on fixe des threads noyau sur les coeurs/processeurs, et où on spawne des threads utilisateur à chaque nouvelle section parallèle (ce qui permettrait peut-être de « coller » au modèle fork/join d'OpenMP, tout en ayant un overhead minimal, et en assurant une possibilité d'avoir des « sections parallèles récursives »).
MPI est super efficace, mais bien trop contraignant à mon goût.