L'avenir d'OpenCL?

Le paradigme de programmation OpenCL promet d'être un standard ouvert sans redevance pour l'informatique hétérogène. Faut-il investir notre temps dans le développement de logiciels basés sur OpenCL? Avantages / inconvénients?

La question est trop large et trop vague pour qu'on y puisse vraiment répondre. Cependant, je vois un point notable contre OpenCL, du point de vue du calcul scientifique, qui est rarement souligné. Jusqu'à présent, aucun effort n'a été fait pour produire des bibliothèques d'infrastructure open source pour OpenCL, tandis que CUDA a plusieurs excellentes options:

• CUBLAS , CUFFT , CUSPARSE
• Poussée , Cusp , OpenCurrent
• Prise en charge PETSc

Je crois que cela nuira vraiment à OpenCL car un facilitateur majeur de l'adoption est des bibliothèques ouvertes de haute qualité.

OpenCL vs quoi?

Si la question est OpenCL vs CUDA, je vois beaucoup de tergiversations sur cette question, et cela me semble fou. Ça n'a pas d'importance. Honnête. Les noyaux - où toute la réflexion doit aller - sont pratiquement identiques entre les deux langues; vous pouvez écrire des macros pour que votre éditeur préféré fasse 99% du travail pour rebondir entre OpenCL et CUDA. Cela doit être ainsi; il s'agit d'un contrôle de bas niveau de types de matériel finalement assez similaires. Une fois que vous avez compris comment écrire vos noyaux importants dans {OpenCL, CUDA}, il est trivial de les porter sur {CUDA, OpenCL}.

Le code hôte passe-partout que vous devez écrire est également similaire, mais CUDA simplifie les cas simples. C'est pourquoi nous enseignons le CUDA dans notre centre; vous pouvez sauter directement dans l'écriture du code du noyau, alors que nous aurions à passer 1-2 heures de notre cours d'une journée à expliquer simplement le lancement du noyau pour OpenCL.

Mais même là, la différence n'est pas si importante; une fois que vous commencez à faire quelque chose de plus compliqué (noyaux asynchrones sur plusieurs gpus), ils sont tous deux aussi compliqués et vous pouvez à nouveau faire une traduction ligne par ligne de l'un à l'autre.

Si c'est OpenCL vs les approches basées sur des directives - OpenACC ou HMPP ou quelque chose - ce sont probablement (espérons-le?) De bonnes façons de programmer ce type d'architectures à l'avenir, où vous pourrez obtenir 90% des performances 10% du travail. Mais quel choix "gagnera" reste à voir et je ne recommanderais pas de passer beaucoup de temps à travailler avec ceux-ci pour l'instant.

Je dirais donc qu'entre CUDA ou OpenCL, choisissez un langage qui vous convient et utilisez-le, et ne vous en faites pas trop. La partie précieuse - trouver comment décomposer votre problème en code SIMD massivement parallèle pour les petits cœurs avec très peu de mémoire - va être assez facilement portable entre les modèles de programmation.

Si vous utilisez du matériel NVIDIA - et vous l'êtes probablement - alors je recommande généralement CUDA - le point de Matt Knepley sur les bibliothèques est sans fondement. Si vous ne l'êtes pas, alors OpenCL.

Que vous deviez investir votre temps dans le développement de logiciels basés sur OpenCL est une question à laquelle vous seul pouvez répondre. S'il semble qu'il a le potentiel de résoudre les problèmes que vous rencontrez en ce moment, et qu'aucune autre solution ouverte ne le fasse, votre meilleure solution est probablement de prendre un risque en mettant en œuvre un petit projet avec lui.

Si cela se passe bien, vous pouvez l'essayer avec des projets plus importants et ainsi de suite jusqu'à ce que vous développiez suffisamment de confiance pour la normaliser, ou que vous la jetiez en faveur d'une autre solution (qui pourrait être votre propre solution propriétaire, une autre solution ouverte ou même une autre solution propriétaire).

Ce qui est merveilleux avec le mouvement open source, c'est que parce que vous avez la source, vous avez tout ce dont vous avez besoin pour bifurquer le projet si nécessaire. Même si la communauté elle-même ne vous offre pas les installations dont vous avez besoin, rien ne vous empêche de mettre en œuvre ces installations vous-même. De plus, si vous vouliez ces installations, il y a une possibilité distincte que d'autres utilisateurs puissent les vouloir, alors nous vous serions reconnaissants si vous apportiez ces modifications au projet principal.

Non seulement cela, mais si vous l'améliorez de votre point de vue, cela pourrait le rendre meilleur pour les autres, les encourager à soumettre leurs propres améliorations et, finalement, améliorer le logiciel pour tout le monde.

Enfin, oui, c'est une réponse plutôt générique à une question plutôt générique. Pour répondre de manière plus complète, nous devons savoir quelles sont vos préoccupations concernant OpenCL. Est-ce la maturité? Soutien communautaire? Facilité d'utilisation? Besoin de temps pour apprendre? Il est temps de se développer? Changer vos procédures? Lorsque vous posez des questions sur les avantages et les inconvénients, à quels autres produits essayez-vous de comparer OpenCL ? Quelles recherches avez-vous déjà faites? De quelles fonctionnalités avez-vous besoin pour prendre en charge votre environnement informatique hétérogène?

Un grand PRO est le nombre de fournisseurs derrière OpenCL. J'ai une expérience anecdotique à ce sujet, après avoir rencontré un groupe de recherche qui a consacré beaucoup de temps et d'efforts à développer un code CUDA assez compliqué pour un système alimenté par NVIDIA. Un an plus tard, après l'élaboration du code, le groupe de recherche a eu accès à un système AMD plus grand et plus rapide, mais il n'a pas pu l'utiliser car il ne disposait pas des ressources (humaines) pour porter le code.

Même si l'ensemble des fonctionnalités de base de CUDA et d'OpenCL sont presque identiques (comme l'a bien souligné @JonathanDursi), si le développeur d'origine n'est pas celui qui est chargé de convertir le code, l'ensemble du projet de portage peut prendre beaucoup de temps.

Cependant, il existe des incompatibilités officielles entre CUDA et OpenCL. Plus particulièrement, CUDA prend en charge les modèles c ++ tandis qu'OpenCL ne les prend pas encore officiellement en charge. Cependant, AMD a fait un effort pour développer une extension à OpenCL avec le support des modèles et d'autres fonctionnalités C ++, plus d'informations dans ce post d'AMD dev central . J'espère qu'une future révision d'OpenCL pourrait ajouter ce travail.

À ce stade (début 2012), les bibliothèques impressionnantes auxquelles @MattKnepley établit un lien vers des sources fermées ou utilisent des modèles, de sorte qu'elles ne seront pas disponibles pour du matériel autre que NVIDIA, du moins dans l'intervalle.

Pour quelqu'un qui apprend le gpu-computing, je dirais que OpenCL C peut être assez difficile, car il y a beaucoup de détails qui distraient l'apprenant des idées de base, tandis que CUDA est plus simple et direct. Cependant, il existe des outils qui rendent OpenCL beaucoup plus simple à apprendre et à utiliser, comme PyOpenCL (le wrapper python pour opencl) qui apporte tout le sucre python à OpenCL (notez qu'il existe également un PyCUDA). Par exemple, la démo PyOpenCL pour ajouter deux tableaux fait un peu moins de 25 lignes et comprend: la création des tableaux sur l'hôte et le périphérique, les transferts de données, la création du contexte et de la file d'attente, le noyau, comment construire et exécuter le noyau , obtenir les résultats du GPU et les comparer avec numpy (voir les liens ci-dessous).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Pour les programmeurs gpu expérimentés, ici je suis d'accord avec @JonathanDursi, CUDA et OpenCL sont fondamentalement les mêmes et il n'y a vraiment aucune différence entre les maires. De plus, le travail acharné de développement d'un algorithme efficace pour les GPU est très indépendant du langage, et la prise en charge d'OpenCL par les fournisseurs et la documentation est maintenant beaucoup plus mature qu'il y a 2 ans. Le seul point qui fait encore une différence, c'est que NVIDIA fait vraiment du bon travail avec son soutien à la communauté CUDA.

OpenCL a l'avantage supplémentaire de pouvoir fonctionner sur les processeurs et est déjà pris en charge par Intel et AMD. Vous n'avez donc pas besoin de modifier votre structure algorithmique si vous souhaitez profiter des cœurs de processeur disponibles. Je ne pense pas qu'OpenCL soit la meilleure solution pour une seule application orientée CPU / multicœur, car un noyau optimisé pour le CPU pourrait avoir un aspect significativement différent d'un noyau optimisé pour le GPU. Cependant, d'après mon expérience, le développement de CODE a l'avantage de pouvoir fonctionner sur le CPU.

Je pense qu'OpenCL souffre actuellement d'un manque de "champion". Par exemple, si vous visitez le site NVIDIA en ce moment (16/12/2011), vous avez plusieurs photos de style "Ken Burns Effect" sur la page d'accueil se concentrant sur le côté scientifique / industriel de l'informatique GPU, et ~ 1 / 4ème de vos options de navigation vous dirigent vers des choses qui finiront probablement chez CUDA. Les fabricants qui vendent des serveurs et des postes de travail "GPU computing" vendent des solutions NVIDIA.

Les offres concurrentes d'ATI sont mélangées avec le site général d'AMD, plus difficiles à trouver et moins présentes dans les solutions tierces. Ces solutions et la possibilité de faire de la programmation basée sur OpenCL existent certainement, mais cela laisse une impression - du moins dans mon esprit, mais dans l'esprit d'autres personnes à qui j'ai parlé - que les grands sponsors corporatifs de la plate-forme OpenCL ont déjà " quitter le champ ". Les utilisateurs d'OS X, par exemple, sont probablement tous trop occupés à spéculer sur l'existence ou non d'une station de travail Apple dans un an pour avoir confiance en eux en poussant le calcul GPU OpenCL.

Le facteur le plus important est que CUDA restera pris en charge uniquement par le matériel NVIDIA.

Ainsi, si vous souhaitez créer un logiciel robuste et portable, OpenCL est la seule option. Tout au plus pouvez-vous construire autour de certaines bibliothèques actuellement alimentées par CUDA et espérer qu'elles seront étendues sur OpenCL à l'avenir en tirant votre code avec.