OpenMP et MPI c'est vraiment pas pareil. Déjà, MPI ne fonctionne « officiellement » qu'avec des processus (même s'il existe des implémentations à base de threads), car c'est ce qui est marqué dans le standard. Ensuite, OpenMP ne propose pas que des appels de fonctions à une bibliothèque, mais aussi un ensemble de directives de compilation et un runtime (pilotable via la bibliothèque et des variables d'environnement). De plus les approches OpenMP et MPI sont différentes :
- MPI propose un ensemble d'appels de fonctions plus complexes (communications 1-1, 1-*, *-*, etc, canaux, en fonction du nombre de processus, etc), et tout doit être explicite. En contrepartie, le principe de MPI est très simple, et une fois assimilé, c'est toujours pareil, et on sait ce qu'on fait. En plus de ça, comme il faut communiquer explicitement quand on utilise MPI, utiliser un programme MPI sur un ou plusieurs nœuds de calcul se fait de façon identique (après il faut espérer que le runtime MPI est assez intelligent pour faire la différence entre communication inter-nœud et intra-nœud).
- OpenMP propose un modèle de programmation basé sur les tâches/threads, en mémoire partagée. Ça exclut d'office le calcul inter-nœud (même s'il existe des machins qui essaient de fabriquer une fausse mémoire globale inter-nœuds, mais pour ce que j'en ai vu, ça marche mal). Comme pour tout prog multithreadé, ça suppose que tout est partagé implicitement, mais du coup on y gagne en empreinte mémoire, on n'a pas besoin de faire d'appel de fonction spécifique pour accéder aux données ou les modifier -- mais par contre il faut toujours faire des synchros à la main...
Les TBB sont un ensemble de templates C++ pour faire de « l'OpenMP » juste avec de la programmation. Cela dit ça va plus loin puisqu'il propose des conteneurs, etc., et aussi moins loin, car le compilateur OpenMP est capable de détecter des choses au niveau de la représentation intermédiaire, en se « souvenant » que plusieurs threads sont mis en jeu, ce qui n'est pas le cas des TBB.
Quant à POP-C++, là aussi a priori le compilateur est du coup capable de générer du code plus efficace vu que les mots-clef sont intégrés au niveau du langage... Mais j'ai des doutes malgré tout sur l'efficacité au final. À tester donc. :)
[^] # Re: Et pourquoi pas OpenMP ?
Posté par lasher . En réponse au message Programmation parallèle en POP-C++. Évalué à 3.
- MPI propose un ensemble d'appels de fonctions plus complexes (communications 1-1, 1-*, *-*, etc, canaux, en fonction du nombre de processus, etc), et tout doit être explicite. En contrepartie, le principe de MPI est très simple, et une fois assimilé, c'est toujours pareil, et on sait ce qu'on fait. En plus de ça, comme il faut communiquer explicitement quand on utilise MPI, utiliser un programme MPI sur un ou plusieurs nœuds de calcul se fait de façon identique (après il faut espérer que le runtime MPI est assez intelligent pour faire la différence entre communication inter-nœud et intra-nœud).
- OpenMP propose un modèle de programmation basé sur les tâches/threads, en mémoire partagée. Ça exclut d'office le calcul inter-nœud (même s'il existe des machins qui essaient de fabriquer une fausse mémoire globale inter-nœuds, mais pour ce que j'en ai vu, ça marche mal). Comme pour tout prog multithreadé, ça suppose que tout est partagé implicitement, mais du coup on y gagne en empreinte mémoire, on n'a pas besoin de faire d'appel de fonction spécifique pour accéder aux données ou les modifier -- mais par contre il faut toujours faire des synchros à la main...
Les TBB sont un ensemble de templates C++ pour faire de « l'OpenMP » juste avec de la programmation. Cela dit ça va plus loin puisqu'il propose des conteneurs, etc., et aussi moins loin, car le compilateur OpenMP est capable de détecter des choses au niveau de la représentation intermédiaire, en se « souvenant » que plusieurs threads sont mis en jeu, ce qui n'est pas le cas des TBB.
Quant à POP-C++, là aussi a priori le compilateur est du coup capable de générer du code plus efficace vu que les mots-clef sont intégrés au niveau du langage... Mais j'ai des doutes malgré tout sur l'efficacité au final. À tester donc. :)