Les techniques usuelles pour gérer la concurrence, à base de verrous etc., ne sont pas génériques et applicables de manière sûre dans tous les cas.
C'est pour cela qu'on a élaboré des modèles sûrs, avec des abstraction de haut niveau, pour la programmation concurrentielle : le message passing surtout, mais aussi un peu les transactions.
On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.
OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire.
En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.
Les pragmas OpenMP ne sont PAS des macros.
Ce sont des pragmas, qui sont des sortes de macros.
Donc ce sont plus ou moins des macros. Ce que je voulais dire de toutes façons, c'est que cela ne s'intégrait pas au langage.
Le standard ne décrit aucun des algorithmes que tu cites
"for" est un algorithme.
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 ?
Je serais fort intéressé de voir un cas où un "for" parallélisé avec OpenMP peut être plus rapide qu'avec une solution sous forme de bibliothèque.
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 */
____}
}
En quoi est-ce plus simple que parallel_for(blocked_range<int>(0, N), /* code parallèle ici sous forme de fonction */);
deuxième forme qui s'intègre bien mieux dans le langage, bien plus générique par ses aspects fonctionnel et d'intervalle (qui peut fonctionner avec tout type d'itérateur), et qui ressemble fortement à std::for_each ?
(Cet algorithme est disponible tel quel dans Intel Threading Building Blocks)
[^] # Re: Concurrence et OpenMP
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 5.
C'est pour cela qu'on a élaboré des modèles sûrs, avec des abstraction de haut niveau, pour la programmation concurrentielle : le message passing surtout, mais aussi un peu les transactions.
On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.
En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.
Ce sont des pragmas, qui sont des sortes de macros.
Donc ce sont plus ou moins des macros. Ce que je voulais dire de toutes façons, c'est que cela ne s'intégrait pas au langage.
"for" est un algorithme.
Je serais fort intéressé de voir un cas où un "for" parallélisé avec OpenMP peut être plus rapide qu'avec une solution sous forme de bibliothèque.
En quoi est-ce plus simple que
parallel_for(blocked_range<int>(0, N), /* code parallèle ici sous forme de fonction */);
deuxième forme qui s'intègre bien mieux dans le langage, bien plus générique par ses aspects fonctionnel et d'intervalle (qui peut fonctionner avec tout type d'itérateur), et qui ressemble fortement à std::for_each ?
(Cet algorithme est disponible tel quel dans Intel Threading Building Blocks)