Discussion :

[MenshaKaine]

bonjour,

les 3 API: OpenMP, OpenCL, intel TBB sont-elle concurrentes ? et servent-elles toutes trois à faire de la programmation parallèle ?

si oui,dans laquelle vaut-il mieux se plonger?

[Christuff]

bonjour,

les 3 api: OpenMP, OpenCL, intel TBB sont-elle concurrente ? et servent-elle touts trois à faire de la programmation parallèle ?

si oui, il vaut mieux se plaonger dans laquelle des 3 ?

Je ne connais pas OpenMP, entre OpenCL et TBB, elles ne sont pas concurrentes ( en tout cas pas a mon gout )

TPP te permettra de paralléliser des taches en utilisant des directives ( #pragma parrallel par exemple ) sur un bloc d'instruction TBB va se charger de diviser la tache pour la repartir sur les processeurs.

OpenCL lui est plus bas niveau et un peu plus complexe, tu va pouvoir faire de la parrallelisation avec mais pour cela tu va devoir te baser sur le modèle OpenCL ( qui ressemble fort a CUDA )
Tu va devoir programmer un kernel que tu appellera pour exécuter ta tache, tu pourra choisir d'exécuter celui-ci sur CPU, GPU ou d'autres plateformes compatibles.
Cependant cela impose naturellement plus de contraintes qu'avec OpenMP ou TBB.

[MenshaKaine]

merci pour ta réponse.

ce qui me parait obscure c'est que dans ces API, il s'agit de diviser les programmes en sous élément pour les exécuter en parallèle !

en plus de ces différentes approches de programmation, peu-être que ces API on des avantages ou des inconvénients différents et surtout des domaines d'application différents !?

[stardeath]

perso je ne connais pas opencl, par contre j'ai utilisé openmp et tbb

tbb avantages :
- concept objet

tbb inconvénients :
- le code doit être à la base pensé pour être parallélisé avec tbb

openmp avantages :
- s'ajoute à peu de frais au code existant (juste l'ajout de quelques pragma)
- ignoré si le compilateur de le supporte pas

openmp inconvénient :
- pas d'objet

bref pour du code existant autant utiliser openmp, pour le reste, autant partir sur tbb

[MenshaKaine]

Donc ca vaut le coup de faire ses développements multi-core a partir de tbb.

Merci pour ta réponse.

[Emmanuel Deloget]

Donc ca vaut le coup de faire ses développements multi-core a partir de tbb.

Merci pour ta réponse.

Pas nécessairement. A l'heure actuelle, OpenMP est standardisé, tandis TBB est une API propre à Intel (bien que écrite pour fonctionner avec d'autres processeurs et compilateurs).

OpenCL n'a, quand à lui, rien à voir avec tout ça. OpenCL, c'est dédié au monde du GPGPU - bien évidemment, on peut programmer des outils massivement parallèle avec OpenCL (c'est même l'idée de base, en fait : déporter des calculs complexes et massivement parallèles sur le GPU)

Personnellement, si je dois y passer, je penserais plus à OpenMP plutôt qu'à TBB. Histoire de support à venir...

[thoratou]

Heu, OpenCL n'est pas reserve qu'au monde du GPGPU. On peut egalement paralleliser sur CPU. Un petit exemple :

[ac_wingless]

TBB est bien plus ambitieux que OpenMP, et à mon avis pas encore assez simple à utiliser, malgré certains progrès. TBB ne peut pas non plus encore être considéré comme un standard malgré sa popularité, parce qu'il y a encore trop d'évolutions (bienvenues).

Voici d'ailleurs ce que dit Intel dans sa FAQ sur TBB à propos de'OpenMP:

What about OpenMP?

Everyone should use OpenMP as much as they can. It is easy to use, it is standard, it is supported by all major compilers, and it exploits parallelism well. But it is very loop oriented, and does not address algorithm or data structure level parallelism. When OpenMP works for your code, you should use it. We’ve seen it used to great advanatage in financial applications, mp3 codecs, scientific programs and high definition video editing software. OpenMP is best geared for Fortran and C code.

Nearly a decade ago we worked with others to create the OpenMP standard, which standardize a set of constructs similar to vector computing directives to fix this for scientific and loop based code. By 2007, we have gotten to the point where every major compiler has support for OpenMP. This is quite an accomplishment, and makes OpenMP the standard way to do parallelism in C and Fortran.

Je pense que ça illustre bien l'état où se trouve TBB: celui d'OpenMP il y a 5 ans. Pour un travail en équipe, nous n'utilisons que OpenMP. Par contre, nous avons dédié en interne un spécialiste TBB. En surface, le code résultant est du C++ bien plus naturel qu'avec OpenMP, mais par contre pour soulever le capot il faut avoir le multi-cœur bien accroché. Par rapport à Boost, où on peut quand même faire des choses sans être trop contaminé par la complexité, TBB est plus bien invasif sur le code utilisateur.

Quand à OpenCL, je n'ai pas encore utilisé en pratique. Si c'est comparable à DirectX Compute, alors c'est quelque chose de très différent de TBB ou OpenMP. On prépare des calculs qu'on déporte sur un système (qu'il soit GPU ou CPU), puis on récupère les résultats.
Dans ma société, tous les calculs "téraflopiques" sont effectués sur GPU, actuellement par DirectX 10, bientôt par DirectX Compute. Nous allons aussi évaluer OpenCL. Mais en aucun cas nous ne mettrions en comparaison ces calculs spécialisés et massifs, avec l'écriture de code parallèle général: pour simplifier, dans un cas on fait des calculs en parallèle, dans l'autre on fait du code parallèle (il y a bien d'autres choses à paralléliser que du calcul). Les deux nous sont utiles, c'est pourquoi nous utilisons pas mal OpenMP, un peu TBB, et beaucoup xLSL. A vous de voir selon vos applications.

[Christuff]

OpenCL n'a, quand à lui, rien à voir avec tout ça. OpenCL, c'est dédié au monde du GPGPU - bien évidemment, on peut programmer des outils massivement parallèle avec OpenCL (c'est même l'idée de base, en fait : déporter des calculs complexes et massivement parallèles sur le GPU)

En théorie OpenCl est destiné a pouvoir s'exécuter sur tout ce qui possède les spécificités requises ( CPU, GPU, cartes d'extension, pot de nutella etc )
En pratique pour le moment seul CPU et GPU possèdent ces jeux, mais ca ne serait pas impossible de voir des cartes d'extensions qui supportent OpenCL

Pour ce qui est de la parallélisation, OpenCL le fait très bien, cela dit si on a pas les besoins de GPU ou de mobilité, a l'heure actuelle, autant ne pas l'utiliser

[MenshaKaine]

Actuellement, je travail sur un projet de traitement d'objet 3D mono thread.

Quand j'observe les performances du code sur des multi-core ca me pique les yeux !

La dessus, je me suis dit, franchement, il doit exister des solutions de parallélisation.

c'est pourquoi, je suis tombé sur ces librairies mais étant novice dans ce domaine, je ne savais pas trop ou aller.

en tout cas vos éléments de réponses m'éclaire.

je pense que je vais regarder dans un premier temps OpenMP, puis TBB je verais ensuite pour OpenCL.

Merci pour vos réponses.

Si des personnes ont des expérience d'utilisation de ces libs, j'aimerai avoir leur avis.

[yamashi]

J'ai utilisé OpenMP pour synchroniser le rendu et la physique dans un jeu vidéo et je dois avouer avoir été très surpris par la facilité d'utilisation d'openMP et surtout pour les itérations des conteneurs STL qui fonctionne nativement en multithread !
Rien à dire donc je suis très satisfait d'OpenMP...
Je n'ai en revanche jamais utilisé TBB donc je ne peux pas comparer.
J'ai utilisé OpenCL au boulot vite fait mais je dois avouer ne pas avoir accroché... Je suis donc resté sous CUDA car OpenCL est moins mature...

[Christuff]

Je n'ai en revanche jamais utilisais TBB donc je ne peux pas comparer.

De mes souvenirs ( je peux me tromper ) il me semble que quand j'avais étudie TBB celui-ci n'aimais pas trop les conteneurs STL ( il valait mieux passer par des tableaux ).
Ceci dit cela remonte a pas loin de 8 mois ...

[MenshaKaine]

@yamashi

merci pour ta réponse.

d'après ce que j'ai lu à droite et à gauche:
openMP reste la solution la plus mature à utiliser.
openCL c'est encore trop frais et pas forcément facile à utiser.
TBB a l'air pas mal aussi.

Je vais voir déjà TBB par curiosité.

[CloudStrife]

Attention c'est pas parce que vous utilisez des outils «magique» que ça va marcher bien tout de suite en parallèle.

Il faut quand même essayer de suivre un certain nombre de règle, qui sont simple mais pas forcement facilement applicable.
- Essayer le moins possible d'accéder au données globales et travailler le plus possible en local. Pour éviter de tomber sur un mutex pour l'accès mémoire.
- Essayer de garder en locale les threads et éviter le changement de CPU, pour rester dans le même cache (sur CPU à cache L2 commun la perte est limité (ça foire juste la L1), mais par exemple les Core 2 Quad sont enfaite (presque) deux dual-core séparé (juste une légère amélioration de l'annulation de cache par rapport à un bi-processeur)).
- Chercher des structures de donnée limitant les blocages lorsque plusieurs éléments veulent y accéder. Par exemple, une liste chaîné où l'on doit faire une modification (ajout, suppression, modification). La solution simple : un gros mutex sur toute la liste. La solution plus complexe mais plus efficaces quand nombreux accès à cette même liste chaîné: mutex locaux sur les éléments qui seront modifié.
- Autre truc qui marche pas mal: refaire un allocateur avec une mémoire local à chaque thread ! Quand on alloue une petite zone mémoire, elle va rentrer dans le «cache» local, pas besoin de faire appelle au malloc système, quand on libre et que c'est dans ce «cache», on ne libère que au niveau de l'allocateur local. Si ça rentre pas dans notre cache (cas d'une grande zone mémoire) et bien là on appelle malloc. L'avantage ? malloc claque un gros mutex lors de l'allocation, deux allocation mémoire ne peuvent pas ce faire en //. Gros gain sur les petites allocations généralement majoritaire non pas en taille mais en nombre.
- Un alignement des données sur la taille des lignes de cache, évite alors que les structures soit à cheval sur plusieurs ligne et donc de faire une annulation de 2 lignes de cache alors que la donnée pourrait rentrer dans une. Et évite de faire une annulation de cache sur une autre donnée présente sur la même ligne. (généralement 64 octets sur les CPU x86 moderne). (On pomme pas mal de place en cache, mais globalement on y gagne)

[Matthieu Brucher]

J'ai utilisé OpenMP pour synchroniser le rendu et la physique dans un jeu vidéo et je dois avouer avoir été très surpris par la facilité d'utilisation d'openMP et surtout pour les itérations des conteneurs STL qui fonctionne nativement en multithread !
Rien à dire donc je suis très satisfait d'OpenMP...
Je n'ai en revanche jamais utilisé TBB donc je ne peux pas comparer.
J'ai utilisé OpenCL au boulot vite fait mais je dois avouer ne pas avoir accroché... Je suis donc resté sous CUDA car OpenCL est moins mature...

Sachant qu'OpenMP ne peut paralléliser des boucles for que si ce sont des entiers, c'est un peu difficile de voir ce que tu fais exactement... OpenMP3 fait apparaître le concept de tâche, mais pour du vrai parallélisme de tâches, OpenMP est, à mon sens, dépassé par TBB qui a été pensé en terme de tâches et non de threads (la bonne approche).

OpenCL, c'est bien, mais c'est nul. Mieux vaut faire, pour le moment, du CUDA, du CAL/IL ou du TBB.

[ac_wingless]

OpenCL, c'est bien, mais c'est nul. Mieux vaut faire, pour le moment, du CUDA, du CAL/IL ou du TBB.

Je ne connais pas OpenCL, mais si je comprends bien c'est assez différent de TBB dans son principe. Peux-tu élaborer ce qui est bien et ce qui est nul? Merci!
Je sais, le sujet est marqué résolu, mais je pense que nous avons tous besoin de retour d'expérience sur ces technologies encore très jeunes.

[Letinono]

Bonjour,

Je ne connais pas les techniques de parallélisation sur CPU. Je n'ai fait que de l'OpenCL et du CUDA.

CUDA n'est dédié qu'aux GPUs nVidia et openCL à tout ce qui possède un driver openCL.

Cependant, il faut savoir qu'OpenCL est plus lent que les instructions SSE sur CPU.

On va donc considérer pour l'instant que ces deux technos permettent d'utiliser les GPUs comme des accélérateurs.

Pour cela, on déporte un partie des calculs sur le GPU. C'est à dire qu'on va préparer les données sur lesquelles on veut travailler, va les envoyer sur le GPU et on va lancer le calcul et on récupère les résultats.

Le code OpenCL et Cuda (kernel) décrivent le fonctionnement d'un élément, cet élément est considéré par nVidia dans CUDA comme un thread, ce qui n'est pas tout à fait le cas.

On va ensuite lancer des milliers de threads qui vont tous effectuer le même calculs, mais sur des données différentes. C'est la la grande différence avec la parallélisation sur CPU.

Le but avec les technos GPGPU est donc d'executer des milliers de fois le même cacul sur des données différentes, en parallèle.

Et c'est là que sont les limites!

- Si on a peu de calculs/peu de données on va rien gagner en temps d'execution, puisqu'on va passer plus de temps à copier des données dans la mémoire GPU qu'à effectuer des calculs dessus.
- Il n'y a pas de système de mutex! On doit donc faire attention à ce que son code n'aille pas écrire ou lire des données traitées par d'autres threads.
- On doit optimiser son code en fonction de son architecture matérielle. Et c'est là que, pour moi on pert tout l'intérêt d'OpenCL qui nous promet un fonctionnement multi-architecture, alors qu'en fait le code doit être pensé pour une architecture particulière pour être optimisé!

La programmation openCL/Cuda est simple si on l'aborde juste pour gagner un peu de temps. Si on veut vraiment pousser les perfs au maximum de la capacité des cartes, il faut se creuser la tête

J'espère avoir apporté un peu d'eau à la discussion

[MatRem]

OpenCL sur CPU peut utiliser SSE.

Il a même un trés gros avantage sur OpenMP, c'est que les kernels sont compilés à l'éxécution ce qui permet au compilateur OpenCL d'optimiser totalement pour la matériel qui va éxécuter le kernel.

Par contre c'est certain OpenMP est beaucoup plus facile à intégrer dans du code c ou c++.