« Il n'y a que deux façons de traiter d'une manière propre la concurrence »
Déjà, dire ça sans argumenter correctement, c'est très limite. Ensuite, le passage de message c'est très bien, mais ça nécessite énormément de boulot car il faut vraiment TOUT gérer. Pour le moment, les mécanismes de mémoire transactionnelle proposent une solution très intéressante, mais du point de vue performance, c'est franchement pas encore ça (mais j'ai bon espoir que ça s'améliore).
OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire. En fait, Il pourrait tout à fait utiliser ces deux mécanismes si les mécanismes étaient présents sur la machine cible, puisqu'il y a une partie compilation, et une partie runtime.
Les pragmas OpenMP ne sont PAS des macros. Il existe une API standard tout à fait utilisable par l'utilisateur, pour permettre d'exploiter plus finement le parallélisme. Le standard ne décrit aucun des algorithmes que tu cites, il spécifie juste les constructions qui sont obligatoires, leur syntaxe, et leurs effets, ainsi que les construction facultatives. Pourquoi en faire quelque chose de dynamique uniquement, quand on est potentiellement capable de détecter à la compilation certaines propriétés importantes pour le parallélisme ? Pour pouvoir paralléliser le code, il faut pouvoir l'analyser en premier lieu ; ce n'est pas avec un code machine où tu as perdu une grande part de la sémantique de ton programme que ça va se faire.
Du point de vue du programmeur d'applications scientifiques, l'utilisation d'OpenMP simplifie grandement la programmation d'applications ayant des sections parallèles : sans avoir à mettre en oeuvre toute la mécanique nécessaire à la parallélisation façon MPI, un programmeur qui sait qu'une portion de son code est parallèle pourra facilement découper celui-ci, en rajoutant un bête #pragma omp parallel
{
____#pragma omp for
____for (i = 0; i < N; i++) {
________/* code parallèle ici */
____}
}
Et je passe sur le fait qu'on peut donner des indications sur la façon de paralléliser (taille des « chunks », c'est-à-dire le nombre d'itérations d'une boucle à donner à chaque thread, nombre de threads à utiliser, variables qui sont privées ou partagées, etc.).
Certains codes se prêtent vraiment très bien à la parallélisation, par exemple tout ce qui est chiffrement par bloc, et le simple fait de faire un #pragma omp parallel for suffit à exploiter correctement le parallélisme du moment qu'on indique au runtime combien de threads créer. Ce code n'est pas isolé.
[^] # Re: Concurrence et OpenMP
Posté par lasher . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 4.
Déjà, dire ça sans argumenter correctement, c'est très limite. Ensuite, le passage de message c'est très bien, mais ça nécessite énormément de boulot car il faut vraiment TOUT gérer. Pour le moment, les mécanismes de mémoire transactionnelle proposent une solution très intéressante, mais du point de vue performance, c'est franchement pas encore ça (mais j'ai bon espoir que ça s'améliore).
OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire. En fait, Il pourrait tout à fait utiliser ces deux mécanismes si les mécanismes étaient présents sur la machine cible, puisqu'il y a une partie compilation, et une partie runtime.
Les pragmas OpenMP ne sont PAS des macros. Il existe une API standard tout à fait utilisable par l'utilisateur, pour permettre d'exploiter plus finement le parallélisme. Le standard ne décrit aucun des algorithmes que tu cites, il spécifie juste les constructions qui sont obligatoires, leur syntaxe, et leurs effets, ainsi que les construction facultatives. Pourquoi en faire quelque chose de dynamique uniquement, quand on est potentiellement capable de détecter à la compilation certaines propriétés importantes pour le parallélisme ? Pour pouvoir paralléliser le code, il faut pouvoir l'analyser en premier lieu ; ce n'est pas avec un code machine où tu as perdu une grande part de la sémantique de ton programme que ça va se faire.
Du point de vue du programmeur d'applications scientifiques, l'utilisation d'OpenMP simplifie grandement la programmation d'applications ayant des sections parallèles : sans avoir à mettre en oeuvre toute la mécanique nécessaire à la parallélisation façon MPI, un programmeur qui sait qu'une portion de son code est parallèle pourra facilement découper celui-ci, en rajoutant un bête
#pragma omp parallel
{
____#pragma omp for
____for (i = 0; i < N; i++) {
________/* code parallèle ici */
____}
}
Et je passe sur le fait qu'on peut donner des indications sur la façon de paralléliser (taille des « chunks », c'est-à-dire le nombre d'itérations d'une boucle à donner à chaque thread, nombre de threads à utiliser, variables qui sont privées ou partagées, etc.).
Certains codes se prêtent vraiment très bien à la parallélisation, par exemple tout ce qui est chiffrement par bloc, et le simple fait de faire un #pragma omp parallel for suffit à exploiter correctement le parallélisme du moment qu'on indique au runtime combien de threads créer. Ce code n'est pas isolé.