Explication de CUDA C et C++
quelqu'un peut-il me donner une bonne explication sur la nature de CUDA C et C++? Si je comprends bien, CUDA est supposé être C avec les bibliothèques GPU de NVIDIA. A partir de Maintenant CUDA C supporte certaines fonctionnalités C++ mais pas d'autres.
Quel est le plan de NVIDIA? Vont-ils construire sur C et ajouter leurs propres bibliothèques (par exemple, Thrust vs. STL) qui correspondent à celles de C++? Vont-ils éventuellement supporter tout le c++? Est-ce mal d'utiliser des en-têtes C++ dans un .cu fichier?
5 réponses
CUDA C est un langage de programmation avec une syntaxe C. Conceptuellement, il est tout à fait différent de C.
le problème qu'il essaie de résoudre est le codage d'instructions multiples (similaires) pour plusieurs processeurs.
CUDA offre plus Qu'un traitement vectoriel à Instruction Multiple (SIMD), mais les flux de données >> les flux d'instruction, ou il y a beaucoup moins d'avantages.
CUDA donne quelques mécanismes pour faire cela, et cache une partie des complexité.
CUDA n'est pas optimisé pour plusieurs flux d'instruction comme un multi-core x86. CUDA n'est pas limité à un seul flux d'instructions comme x86 vector instructions, ou limité à des types de données spécifiques comme x86 vector instructions.
CUDA supporte les boucles qui peuvent être exécutées en parallèle. C'est sa forme la plus caractéristique essentielle. Le système CUDA partitionnera l'exécution de 'loops', et exécutera le corps de 'loop' simultanément à travers un tableau de les processeurs, tout en fournissant une partie de l'illusion d'une boucle séquentielle normale (spécifiquement CUDA gère la boucle "index"). Le développeur doit être conscient de la structure de la machine GPU pour écrire des "boucles" efficacement, mais presque toute la gestion est gérée par le Cuda run-time. L'effet est des centaines (ou même des milliers) de 'boucles' complètes en même temps qu'une 'boucle'.
CUDA supporte ce qui ressemble à if les branches. Seuls les processeurs exécutant un code qui correspond au test if peuvent être actif, donc un sous-ensemble de processeurs sera actif pour chaque "branche" de la si test. Comme un exemple de ceci if... else if ... else ..., a trois branches. Chaque processeur d'exécuter une seule branche, et être "re-synchronisé' prêt à passer le reste de l'processeurs lorsque la si est terminée. Il se peut que certaines conditions de la branche ne correspondent à aucun processeur. Il n'est donc pas nécessaire d'exécuter cette branche (par exemple, trois branches est le pire des cas). Ensuite, seulement une ou deux branches sont exécutées de manière séquentielle, de l'achèvement de l'ensemble du if plus rapidement.
Il n'y a pas de "magie". Le programmeur doit être conscient que le code sera exécuté sur un périphérique CUDA, et écrire le code consciemment pour lui.
CUDA ne prend pas le vieux code C / C++ et auto-magiquement exécutez le calcul sur un tableau de processeurs. CUDA peut compiler et exécuter du C ordinaire et une grande partie du C++ de façon séquentielle, mais il y a très peu (rien?) pour être gagné par cette raison, il sera exécuté séquentiellement, et plus lentement qu'un CPU moderne. Cela signifie que le code de certaines bibliothèques ne correspond pas (encore) aux capacités de CUDA. Un programme CUDA pourrait fonctionner simultanément sur des vecteurs bit multi-kByte. CUDA n'est pas en mesure de auto-magiquement convertissez le code séquentiel C/C++ de la bibliothèque en quelque chose qui ferait cela.
CUDA fournit une façon relativement simple d'écrire du code, en utilisant la syntaxe familière C/C++, ajoute quelques concepts supplémentaires, et génère code qui s'exécute sur un tableau de processeurs. Il a le potentiel de donner beaucoup plus que la vitesse 10x vs par exemple multi-core x86.
Modifier les Plans: je ne travaille pas pour NVIDIA
pour la meilleure performance CUDA veut des informations au moment de la compilation.
ainsi les mécanismes de template sont les plus utiles car ils donnent au développeur un moyen de dire des choses au moment de la compilation, que le compilateur CUDA pourrait utiliser. Comme exemple simple, si une matrice est définie (instanciated) au moment de la compilation pour être 2D et 4 x 8, alors le compilateur CUDA peut travailler avec cela pour organiser le programme à travers les processeurs. Si cette taille est dynamique, et change pendant que le programme tourne, c'est beaucoup plus difficile pour le compilateur ou le système d'exécution de faire un travail très efficace.
modifier: CUDA a des modèles de classes et de fonctions. Je m'excuse si les gens lisent ceci comme disant que CUDA ne le fait pas. Je suis d'accord je n'étais pas clair.
je crois que L'implémentation de CUDA GPU-side des modèles n'est pas complète.w.r.t. C++.
l'utilisateur harrism a commenté que ma réponse est trompeuse. harrism travaille pour NVIDIA, donc je vais attendre des conseils. J'espère que c'est déjà plus claire.
la chose la plus difficile à faire efficacement à travers plusieurs processeurs est la ramification dynamique vers le bas beaucoup de chemins alternatifs parce que cela sérialise effectivement le code; dans le pire des cas, seul un processeur peut exécuter à la fois, ce qui gaspille l'avantage d'un GPU. Ainsi les fonctions virtuelles semblent pour être très difficile à faire.
il existe des outils d'analyse de programme complets très intelligents qui permettent de déduire beaucoup plus d'informations de type que le développeur pourrait comprendre. Les outils existants pourraient en déduire assez pour éliminer les fonctions virtuelles, et donc déplacer l'analyse de branchement pour compiler le temps. Il existe également des techniques pour instrumenter l'exécution de programme qui alimente directement en recompilation de programmes qui pourraient atteindre de meilleures décisions de branchement.
AFAIK (modulo feedback) le compilateur CUDA n'est pas encore à la pointe dans ces domaines.
(IMHO cela vaut quelques jours pour toute personne intéressée, avec un système CUDA ou OpenCL-capable, pour les étudier, et faire quelques expériences. Je pense également, pour les personnes intéressées par ces domaines, il est bien la peine de l'effort pour expérimenter avec Haskell, et jeter un oeil à Parallèle Des Données Haskell)
CUDA est une plate-forme (architecture, modèle de programmation, machine virtuelle d'assemblage, outils de compilation, etc.), et pas seulement un seul langage de programmation. CUDA C n'est qu'un des nombreux systèmes linguistiques construits sur cette plateforme (CUDA C, C++, CUDA Fortran, PyCUDA, etc.).)
CUDA C++
actuellement CUDA C++ supporte le sous-ensemble de C++ décrit dans L'Annexe D ("C / C++ Language Support") du CUDA C Programming Guide.
pour nommer un quelques:
- Classes
__device__fonctions des membres (y compris les constructeurs et les destructeurs)- classes D'héritage / dérivées
- fonctions virtuelles
- classe et les modèles de fonction
- opérateurs et surcharge
- foncteur classes
Edit: à partir de CUDA 7.0, CUDA C++ inclut la prise en charge de la plupart des fonctionnalités linguistiques du standard C++11 dans __device__ (le code qui s'exécute sur le GPU), y compris auto, les expressions lambda, basés sur la plage pour les boucles, l'initialiseur de listes, statique affirmer, et plus encore.
les exemples et les limitations spécifiques sont également détaillés dans la même annexe liée ci-dessus. Comme un exemple très mature de L'utilisation de C++ avec CUDA, je recommande de vérifier Poussée.
Plans D'Avenir
(divulgation: je travaille pour NVIDIA.)
Je ne peux pas être explicite sur les futures versions et le timing, mais je peux illustrer la tendance que presque chaque version de CUDA a ajouté des fonctionnalités de langage supplémentaires pour obtenir la prise en charge de CUDA C++ dans son état actuel (à mon avis Très utile). Nous prévoyons de poursuivre cette tendance en améliorant le support pour C++, Mais Naturellement nous priorisons les fonctionnalités qui sont utiles et performantes sur une architecture computationnelle massivement parallèle (GPU).
non réalisé par beaucoup, CUDA est en fait deux nouveaux langages de programmation, tous deux dérivés de C++. L'un est pour écrire du code qui tourne sur GPUs et est un sous-ensemble de C++. Sa fonction est similaire à HLSL (DirectX) ou Cg (OpenGL) mais avec plus de fonctionnalités et de compatibilité avec C++. Diverses préoccupations liées à la GPGPU/SIMT/performance s'appliquent à elle que je n'ai pas besoin de mentionner. L'autre est ce qu'on appelle l ' "API D'exécution", qui n'est guère une "API" au sens traditionnel du terme. L'API Runtime est utilisée pour écrire du code qui fonctionne sur le processeur hôte. C'est un super-ensemble de C++ et il est beaucoup plus facile de se connecter au code GPU et de le lancer. Il nécessite le pré-compilateur NVCC qui appelle alors le compilateur C++ de la plate-forme. En revanche, L'API de pilote (et OpenCL) est une bibliothèque C pure et standard, et est beaucoup plus verbeuse à utiliser (tout en offrant peu de fonctionnalités supplémentaires).
la création d'un nouveau langage de programmation côté hôte a été un geste audacieux de la part de NVIDIA. Cela rend plus facile de commencer avec CUDA et d'écrire du code plus élégant. Cependant, truly brilliant ne le commercialisait pas comme une nouvelle langue.
parfois vous entendez que CUDA serait C et C++, mais je ne pense pas que ce soit, pour la simple raison que c'est impossible. Pour citer un extrait de leur guide de programmation:
pour le code hôte, nvcc supporte n'importe quelle partie du C++ ISO / IEC 14882: 2003 spécification prise en charge par le compilateur hôte c++.
pour le code de périphérique, nvcc supporte les fonctionnalités illustrées dans la Section D. 1 avec certaines restrictions décrites à la Section D. 2; elle ne soutien de l'exécution information sur le type (RTTI), traitement des exceptions et C++ De La Bibliothèque Standard.
comme je peux le voir, il ne se réfère qu'à C++, et ne supporte C que lorsque cela se trouve à l'intersection de C et C++. Alors pensez plutôt à C++ avec des extensions pour la partie périphérique plutôt que C. Cela vous évite beaucoup de maux de tête si vous êtes habitué à C.
Quel est le plan de NVIDIA?
je crois que la tendance générale est que CUDA et OpenCL sont considérés comme des techniques de niveau trop bas pour de nombreuses applications. En ce moment, Nvidia investit massivement dans OpenACC qui pourrait être grossièrement décrit comme OpenMP pour les GPU. Il suit une approche déclarative et aborde le problème de la parallélisation des GPU à un niveau beaucoup plus élevé. C'est donc mon impression totalement subjective de ce qu'est le plan de Nvidia.