J'aimerais entendre des personnes ayant une expérience du codage pour les deux. Moi-même, je n'ai d'expérience qu'avec NVIDIA.

NVIDIA CUDA semble être beaucoup plus populaire que la concurrence. (Il suffit de compter les balises de questions sur ce forum, «cuda» surpasse «opencl» 3: 1, et «nvidia» surpasse «ati» 15: 1, et il n'y a pas de balise pour «ati-stream» du tout).

D'un autre côté, selon Wikipedia, les cartes ATI / AMD devraient avoir beaucoup plus de potentiel, surtout par dollar. La carte NVIDIA la plus rapide du marché à ce jour, GeForce 580 (500 $), est évaluée à 1,6 TFlops en simple précision. AMD Radeon 6970 peut être obtenu pour 370 $ et il est évalué à 2,7 TFlops. Le 580 dispose de 512 unités d'exécution à 772 MHz. Le 6970 a 1536 unités d'exécution à 880 MHz.

Dans quelle mesure cet avantage papier d'AMD par rapport à NVIDIA est-il réaliste et est-il susceptible de se concrétiser dans la plupart des tâches GPGPU? Que se passe-t-il avec les tâches entières?

Métaphoriquement parlant, ati a un bon moteur par rapport à nvidia. Mais nvidia a une meilleure voiture: D

Ceci est principalement dû au fait que nvidia a investi une bonne partie de ses ressources (en argent et en personnel) pour développer des bibliothèques importantes nécessaires au calcul scientifique (BLAS, FFT), puis à nouveau un bon travail dans sa promotion. Cela peut être la raison pour laquelle CUDA domine les balises ici par rapport à ati (ou OpenCL)

Quant à l'avantage étant réalisé dans les tâches GPGPU en général, il finirait par dépendre d'autres problèmes (selon l'application) tels que, la bande passante de transfert de mémoire, un bon compilateur et probablement même le pilote. nvidia ayant un compilateur plus mature, un pilote plus stable sur linux (linux car, son utilisation est répandue dans le calcul scientifique), fait pencher la balance en faveur de CUDA (du moins pour l'instant).

EDIT 12 janvier 2013

Cela fait deux ans que j'ai publié ce post et il semble encore parfois attirer les vues. J'ai donc décidé de clarifier quelques points

• AMD a intensifié son jeu. Ils ont maintenant des bibliothèques BLAS et FFT. De nombreuses bibliothèques tierces surgissent également autour d'OpenCL.
• Intel a introduit Xeon Phi dans la nature, prenant en charge à la fois OpenMP et OpenCL. Il a également la capacité d'utiliser le code x86 existant. comme indiqué dans les commentaires, x86 limité sans SSE pour le moment
• NVIDIA et CUDA ont toujours l'avantage dans la gamme de bibliothèques disponibles. Cependant, ils ne se concentrent peut-être pas autant sur OpenCL qu'avant.

En bref, OpenCL a comblé l'écart au cours des deux dernières années. Il y a de nouveaux joueurs dans le domaine. Mais CUDA est encore un peu en avance sur le peloton.

Je n'ai pas de sentiments forts à propos de CUDA vs OpenCL; vraisemblablement OpenCL est l'avenir à long terme, juste à force d'être un standard ouvert.

Mais les cartes NVIDIA vs ATI actuelles pour GPGPU (pas les performances graphiques, mais GPGPU), sur lesquelles j'ai une forte opinion. Et pour y conduire, je ferai remarquer que sur la liste actuelle des 500 grands clusters , NVIDIA mène les systèmes AMD 4 à 1, et sur gpgpu.org , les résultats de recherche (articles, liens vers des ressources en ligne, etc.) pour NVIDIA sont plus nombreux que les résultats pour AMD 6: 1.

Une grande partie de cette différence est la quantité d'informations en ligne disponibles. Découvrez la zone NVIDIA CUDA par rapport à GPGPU Developer Central d' AMD . La quantité de choses là pour les développeurs qui démarrent n'est même pas proche de la comparaison. Sur le site de NVIDIA, vous trouverez des tonnes de documents - et de code contributif - de personnes travaillant probablement sur des problèmes comme le vôtre. Vous trouverez des tonnes de cours en ligne, de NVIDIA et d'ailleurs, et des documents très utiles comme le guide des meilleures pratiques des développeurs, etc.

(Editeur: les informations de ce paragraphe ne sont plus exactes.) Et une partie de la différence est également matérielle. Les cartes AMD ont de meilleures spécifications en termes de flops de pointe, mais pour pouvoir en obtenir une fraction significative, vous devez non seulement diviser votre problème sur de nombreux processeurs de flux complètement indépendants, mais chaque élément de travail doit également être vectorisé. Étant donné que le code GPGPU est déjà assez difficile, cette complexité architecturale supplémentaire est suffisante pour faire ou défaire certains projets.

Et le résultat de tout cela est que la communauté d'utilisateurs NVIDIA continue de croître. Sur les trois ou quatre groupes que je connais qui envisagent de créer des clusters GPU, aucun d'entre eux n'envisage sérieusement les cartes AMD. Et cela signifiera encore plus de groupes qui rédigeront des articles, contribueront au code, etc. du côté de NVIDIA.

Je ne suis pas un shill NVIDIA; J'aimerais que ce ne soit pas le cas, et qu'il y ait deux (ou plus!) Plates-formes GPGPU tout aussi convaincantes. La concurrence est bonne. Peut-être qu'AMD intensifiera son jeu très bientôt - et les produits de fusion à venir semblent très convaincants. Mais en donnant à quelqu'un des conseils sur les cartes à acheter aujourd'hui et où passer son temps à faire des efforts maintenant, je ne peux pas en toute conscience dire que les deux environnements de développement sont tout aussi bons.

Modifié pour ajouter : je suppose que ce qui précède est un peu elliptique en termes de réponse à la question originale, alors laissez-moi le rendre un peu plus explicite. Les performances que vous pouvez obtenir à partir d'un morceau de matériel sont, dans un monde idéal avec un temps infini disponible, dépendant uniquement du matériel sous-jacent et des capacités du langage de programmation; mais en réalité, la quantité de performances que vous pouvez obtenir en un temps fixe investi dépend également fortement des outils de développement, des bases de code communautaire existantes (par exemple, les bibliothèques accessibles au public, etc.). Ces considérations pointent toutes fortement vers NVIDIA.

(Editeur: les informations de ce paragraphe ne sont plus exactes.) En termes de matériel, l'exigence de vectorisation au sein des unités SIMD des cartes AMD rend également l'obtention de performances papier encore plus difficile qu'avec le matériel NVIDIA.

La principale différence entre les architectures AMD et NVIDIA est qu'AMD est optimisé pour les problèmes où le comportement de l'algorithme peut être déterminé au moment de la compilation, tandis que NVIDIA est optimisé pour les problèmes où le comportement de l'algorithme ne peut être déterminé qu'au moment de l'exécution.

AMD a une architecture relativement simple qui leur permet de passer plus de transistors sur les ALU. Tant que le problème peut être entièrement défini au moment de la compilation et être mappé avec succès à l'architecture de manière quelque peu statique ou linéaire, il y a de fortes chances qu'AMD soit capable d'exécuter l'algorithme plus rapidement que NVIDIA.

D'un autre côté, le compilateur de NVIDIA effectue moins d'analyses au moment de la compilation. Au lieu de cela, NVIDIA a une architecture plus avancée où ils ont passé plus de transistors sur une logique capable de gérer le comportement dynamique de l'algorithme qui n'apparaît qu'au moment de l'exécution.

Je crois que le fait que la plupart des supercalculateurs qui utilisent des GPU sont compatibles avec NVIDIA est que le type de problème sur lequel les scientifiques sont intéressés à exécuter des calculs, en général, correspond mieux à l'architecture de NVIDIA qu'à AMD.

J'ai fait du codage itératif dans OpenCL. Et les résultats de son exécution dans NVIDIA et ATI sont à peu près les mêmes. Près de la même vitesse dans les cartes de même valeur ($).

Dans les deux cas, les vitesses étaient d'environ 10x-30x par rapport à un processeur.

Je n'ai pas testé CUDA, mais je doute que cela puisse résoudre mes problèmes de récupération de mémoire aléatoire par magie. De nos jours, CUDA et OpenCL sont plus ou moins les mêmes, et je vois plus d'avenir sur OpenCL que sur CUDA. La raison principale est qu'Intel lance des pilotes avec OpenCL pour leurs processeurs. Ce sera une énorme avancée dans le futur (l'exécution de 16, 32 ou 64 threads d'OpenCL dans le CPU est VRAIMENT rapide et vraiment facile à porter sur GPU).

Ayant passé du temps avec OpenCL pour les cartes GCN après quelques années de CUDA pour Fermi et Kepler, je préfère toujours CUDA comme langage de programmation et choisirais le matériel AMD avec CUDA si j'avais une option.

Principales différences entre NVIDIA et AMD (OpenCL):

Pour AMD:

• Même avec Maxwell, NVidia a toujours des latences de commande plus longues et les algorithmes complexes seront probablement 10 plus rapides sur AMD (en supposant les mêmes Tflops théoriques) après des optimisations faciles pour les deux. L'écart était jusqu'à 60% pour Kepler VS GCN. Dans ce sens, il est plus difficile d'optimiser les noyaux complexes pour NVidia.

• Cartes bon marché.

• OpenCL est un standard ouvert avec d'autres fournisseurs disponibles.

Pour Nvidia:

• Possède la gamme de matériel Tesla qui convient aux charges de serveur élevées et fiables.

• Le nouveau Maxwell est beaucoup plus économe en énergie.

• Le compilateur et les outils sont bien plus avancés. AMD ne peut toujours pas implémenter le maxregcoutparamètre, vous pouvez donc facilement contrôler l'occupation sur divers matériels et leur compilateur a beaucoup d'idées aléatoires sur ce qu'est un code optimal qui change avec chaque version, vous devrez donc peut-être revoir l'ancien code toutes les moitiés. un an parce qu'il est devenu soudainement 40% plus lent.

À ce stade, si GPGPU est votre objectif, CUDA est le seul choix, car opencL avec AMD n'est pas prêt pour la ferme de serveurs et il est beaucoup plus difficile d'écrire du code efficace pour AMD en raison du fait que le compilateur semble toujours être "en version bêta" .

Je suis nouveau sur GPGPU mais j'ai une certaine expérience en informatique scientifique (doctorat en physique). Je suis en train de constituer une équipe de recherche et je souhaite aller vers l'utilisation de GPGPU pour mes calculs. J'ai dû choisir entre les plateformes disponibles. J'ai opté pour Nvidia, pour plusieurs raisons: bien que l'ATI soit plus rapide sur papier, Nvidia dispose d'une plate-forme plus mature et de plus de documentation, il sera donc possible de se rapprocher des performances de pointe sur cette plate-forme.

Nvidia a également un programme de soutien à la recherche académique, on peut faire une demande de soutien, je viens de recevoir une carte TESLA 2075 dont je suis très heureux. Je ne sais pas si ATI ou Intel prend en charge la recherche de cette façon.

Ce que j'ai entendu à propos d'OpenCL, c'est qu'il essaie d'être tout à la fois, il est vrai que votre code OpenCL sera plus portable, mais il est également susceptible d'exploiter toutes les capacités de l'une ou l'autre des plates-formes. Je préfère en apprendre un peu plus et écrire des programmes qui utilisent mieux les ressources. Avec le TESLA K10 qui vient de sortir cette année, Nvidia est dans la gamme 4,5 TeraFlops donc il n'est pas clair que Nvidia soit en retard ... Cependant, les MIC Intel pourraient s'avérer être un vrai concurrent, surtout s'ils réussissent à déplacer l'unité GPGPU vers la carte mère. Mais pour l'instant, j'ai choisi Nvidia.

Mon expérience dans l'évaluation des performances en virgule flottante OpenCL tend à favoriser les cartes NVIDIA. J'ai travaillé avec quelques benchmarks en virgule flottante sur des cartes NVIDIA allant de la 8600M GT à la GTX 460. Les cartes NVIDIA atteignent systématiquement environ la moitié du pic théorique de précision unique sur ces benchmarks.
Les cartes ATI avec lesquelles j'ai travaillé atteignent rarement mieux qu'un tiers du pic de précision simple. Notez que mon expérience avec ATI est biaisée; Je n'ai pu travailler qu'avec une seule carte de la série 5000. Mon expérience concerne principalement les cartes de la série HD 4000, qui n'ont jamais été bien prises en charge. La prise en charge des cartes de la série HD 5000 est bien meilleure.

Je voudrais ajouter au débat. Pour nous, dans le secteur des logiciels, nous pouvons compromettre les performances brutes en simple précision à la productivité, mais même cela je n'ai pas à faire de compromis car, comme déjà souligné, vous ne pouvez pas obtenir autant de performances sur le matériel d'ATI en utilisant OpenCL que vous pouvez le faire. si vous écrivez dans CUDA sur le matériel de NVIDIA.

Et oui, avec l'annonce par PGI du compilateur x86 pour CUDA, il n'y aura aucune bonne raison de passer plus de temps et de ressources à écrire en OpenCL :)

PS: Mon argument pourrait être biaisé puisque nous faisons presque tout notre travail GPGPU sur CUDA. Nous avons une bibliothèque de traitement d'image / vision par ordinateur CUVI (CUDA pour la vision et l'imagerie) qui accélère certaines fonctionnalités IP / CV de base sur CUDA.

Cuda est certainement plus populaire qu'OpenCL à ce jour, car il est sorti 3 ou 4 ans avant OpenCL. Depuis la sortie d'OpenCL, Nvidia n'a pas beaucoup contribué pour le langage car ils se concentrent beaucoup sur CUDA. Ils n'ont même pas publié la version openCL 1.2 pour aucun pilote.

En ce qui concerne l'informatique hétérogène ainsi que les appareils portables, OpenCl gagnera certainement en popularité dans un proche avenir. AMD est désormais le plus gros contributeur d'OpenCL, visible sur leur site.

dans mon expérience:

• si vous voulez les meilleures performances absolues, vous devez voir qui utilise la dernière itération matérielle et utiliser leur pile (y compris les dernières versions / bêta).

• si vous voulez les meilleures performances pour votre argent, vous viserez des cartes gamer plutôt que des cartes "professionnelles" et la flexibilité de cibler différentes plates-formes favorise opencl.

• si vous débutez, en particulier, cuda a tendance à être plus raffiné et à avoir plus d'outils et de bibliothèques.

enfin, mon point de vue personnel, après un «soutien» épouvantable de la part de nvidia (nous avons eu un tesla mort et cela n'a pas été changé pendant des mois, alors qu'un client attendait): la flexibilité de quitter le navire avec opencl vaut le risque d'une performance légèrement inférieure lorsque nvidia est en avance dans le cycle de publication.