Le SC11 aura vu débarquer officiellement un énième langage destiné aux accélérateurs massivement parallèle, et en particulier aux GPU : OpenACC. Standard ...
Lire la suite ...

Bonjour,
 
C'est très intéressant.
 
Je me permets un petit commentaire concernant la phrase "OpenCL est une version étendue et ouverte de C pour CUDA". Sans entrer dans une guerre de chapelles (pour laquelle ma neutralité est discutable), je tiens à préciser que pour ce qui concerne la programmation GPU, OpenCL est un sous-ensemble de CUDA (CUDA supporte le C++ avec l'héritage, les templates alors que OpenCL se "contente" du C. De plus, CUDA offre de nombreuses fonctionnalités de gestion de multiples GPU alors qu'OpenCL ne le fait pas). En revanche, il est vrai qu'OpenCL est ouvert (défini par le comité Khronos qui gère aussi OpenGL) et qu'il offre la possibilité aux vendeurs d'ajouter des extensions comme avec OpenGL.

Ça a toujours été la solution la meilleure, le compilateur étant difficile a optimiser mais finalement c'est a son niveau que les optimisations sont les plus efficaces. Une amélioration du compilateur profite a tout le monde, et donc rentabilise l'investissement de manière plus rationnelle, au contraire d'une optimisation du programme en lui même, a coup de code CUDA ultra pointu qui ne servira qu'au programme. La seule difficulté consiste donc a trouver les ressources pour les compilateurs.

 
Bonjour, on peut bien entendu toujours jouer sur les mots (cf CUDA, l'architecture compute, vs C pour CUDA, le langage ). Pour être exact dans le sens recherché, étendu à d'autres architectures et à leurs spécificités qui peuvent aller au delà de ce dont sont capables les devices CUDA, j'aurai probablement dû préciser "OpenCL est une version étendue et ouverte du mode driver de C pour CUDA 2.x", mais il s'agit d'un détail qui n'aurait pas eu de sens dans une phrase sensée définir OpenCL d'une manière simple.

Il n'aura échappé à personne que CUDA (architecture et langage) en est à la version 4.0 (CUDA 4.1 est en phase de RC1).

Le but n'était pas de comparer en détail OpenCL à CUDA ni de nier à CUDA ses évolutions récentes. Cette phrase est destinée à faire un parallèle entre la mise en place d'OpenACC et celle d'OpenCL il y a quelques années, ce dernier n'ayant de manière évidente pas pu être tiré en 2008 d'une version de CUDA de 2011.

@jdemouth: OpenCL permet parfaitement de gérer de multiples GPUs ET CPUs. Allez voir du côté du moteur de rendu LuxRender, et en particulier des programmes expérimentaux SmallLuxGPU, ou encore LuxMark développés par Dade (David Bucciarelli). Ce dernier est d'ailleurs utilisé comme benchmark par divers sites de tests hardware...

 
OpenCL permet de piloter plusieurs GPUs, mais cela se fait d'une manière indirecte. C'est au développeur de prévoir plusieurs contextes OpenCL et de diriger spécifiquement des tâches vers chaque device existant. C'est plus contraignant et peu efficace pour certains algorithmes. CUDA est plus avancé à ce niveau : par exemple, un seul thread peut accéder directement à plusieurs GPUs, chaque GPU a accès directement à la mémoire des autres (grâce à un espace mémoire unifié)...

@Tantor49: OpenCL permet effectivement de gérer plusieurs GPUs et CPUs. Ce que je cherchais à dire -- et je me suis probablement mal exprimé -- est que CUDA offre des fonctionnalités supplémentaires pour les codes multi-GPU. Comme Damien le dit, CUDA 4.x offre la possibilité d'accéder à un espace mémoire unifié entre CPU et GPU (le driver se charge de déterminer si une adresse référence une zone mémoire du CPU ou du GPU). Ceci n'est pas possible avec OpenCL (qui ne propose pas de pointeurs). Avec CUDA 4.x, un GPU peut accéder à la mémoire d'un autre GPU sans que le code CPU n'ait besoin de faire le transfert (GPUDirect).

Pour en revenir à OpenACC, il me semble (mais ce n'est que mon avis) que si un langage de directives de ce genre venait à être largement adopté (à l'image d'OpenMP), l'intérêt d'OpenCL serait fortement réduit. On aurait 99% du code qui serait écrit en C/C++ (voire Fortran ) + OpenACC. Le 1% de code critique restant pourrait être écrit en "assembleur" (CUDA sur les GPUs Nvidia - un équivalent sur AMD).

On est d'accord sur ce point

Comme pour OpenMP, j'ai quand même un doute sur l'approche... certes ici c'est un peu plus propre, mais on est dans du partage de tâches de très haut niveau.
 
D'ailleurs, ça fait un peu peur de les voir parler d'intégrer OpenACC à OpenMP, on sent poindre l'usine à gaz tellement compliquée que ça n'aura plus guère d'intérêt.

@Gigathlon: Il me semble que tous les acteurs du marché des calculateurs s'orientent dans la direction des langages de directives. De nombreux codes sont aujourd'hui écrits de façon séquentielle par des gens dont l'informatique n'est pas le domaine de compétences premier. Bien qu'OpenMP ne permette pas de "tout faire" en matière de parallèlisme CPU, il offre des possibilités suffisantes pour une majorité d'utilisateurs. Pour les GPU, CUDA (ou OpenCL) ne sont pas à la portée de tous les développeurs et une approche à base de directives, même si elle a ses limites, permet de toucher plus de monde. Ceci dit, il y aura toujours de la place pour les quelques "ninjas" de la programmation qui sont prêts à consacrer le temps nécessaire pour maîtriser les subtilités des architectures HW et/ou langages.

 
L'interêt pour OpenCL ne sera pas réduit. Ces technos de compilation 'haut niveau' ont besoin d'OpenCL pour accéder à l'accélerateur de multiples fabricants de hardware. Par example HMPP genère du code OpenCL. OpenACC permettra simplement à des gens non familiers avec la programmation de bas niveau d'utiliser un accelerateur. Les boites qui font du middleware, par exemple des moteurs de jeu, eux utiliseront directement OpenCL.

@_gotcha_: Je ne partage pas cet avis. Pour faire un code optimisé au maximum il est nécessaire d'avoir accès aux instructions spécifiques du matériel. Par exemple, OptiX (la bibliothèque de raytracing Nvidia) fait probablement énormément usage des instructions de warp (__any, __all et __ballot) qui ne sont pas exposées en OpenCL. C'est pareil pour AMD, les instructions HW ne sont pas exposées en OpenCL. Le compilateur en a besoin pour générer le code le plus efficace.

@jdemouth : Effectivement, idealement, le compilateur doit generer du code spécifiques pour chaque plateforme, mais je ne pense pas que tous ceux qui developpent des compilateurs aient les moyens de developper un backend specifique pour tous les accelerateurs (en terme ressources mais aussi en terme d'accès aux details des architectures cibles). Nvidia developpera peut-être son compilateur OpenACC spécifique pour ses GPU, mais pour les autres (AMD, Intel, IBM et autres), j'ai quand même l'impression qu'il faudra passer par OpenCL.  
 
Ceci étant dit, si Nvidia le voulait, ils pourraient proposer les fonctions de warp enoncées en extension OpenCL specifique pour les work-groups. Mais encore faut il le vouloir ... :-)