Discussion :

[fred61]

Bonjour,

Je fais des programmes mathématiques sur des bignumbers devant effectuer des milliards de calculs. J'ai crus comprendre qu'il était possible d'utiliser la carte graphique en parallèle pour partager les calculs avec le CPU.
Est-ce que vous savez comment procéder, j'ai fais des recherches sur le net et j'ai lu quelques articles sur CUDA, mais il n'y a pas beaucoup d'infos ?

Merci.

[GuruuMeditation]

CUDA est le seul que je connais. J'avais un peu regardé il y a quelques années. J'avais trouvé ça, pas sûr que ce soit encore d'actualité : http://www.c-sharpcorner.com/uploadf...-with-C-Sharp/

[Graffito]

Je fais des programmes mathématiques sur des bignumbers devant effectuer des milliards de calculs. J'ai crus comprendre qu'il était possible d'utiliser la carte graphique en parallèle pour partager les calculs avec le CPU.

As-tu d'abord pensé à créer autant de thread que de processeurs logiques (propriété Environment.ProcessorCount) ?
Note : En cas d'hyperthreading, le nombre de processeurs logiques est égal au nombre de processeurss physiques x 2, soit 8 pour un Core I7.

[DonQuiche]

CUDA est spécifique aux produits NVidia et sur le déclin, aujourd'hui on utilise OpenCL, qui est le standard du GPGPU géré par le même consortium que OpenGL. Pour dotnet il existe le bien nommé OpenCL.net. Rien de très sorcier en toute franchise, une fois que tu auras vu un exemple en C# et son kernel associé tu auras compris l'idée : on envoie un tableau (1D/2D/3D) et un programme ("kernel") à effectuer pour chaque élément du tableau.



C'est très efficace mais également beaucoup plus limité. Un GPU n'est pas du tout comme un CPU qui aurait seulement plus de coeurs.

* Un "kernel" est découpé en dizaines de "warps" tous indépendants les uns des autres. Jusque là tout va bien. En revanche chaque warp contient des dizaines de "threads" (32 typiquement) qui tous exécutent la même instruction en même temps ! Donc si par exemple on place un branchement conditionnel ("if") dont la condition est vraie 50% du temps, alors 50% des threads d'un warp s'exécutent pendant que les autres sont mis en attente. C'est la grande force et la grande faiblesse du GPU.

* Chaque warp a son propre cache mémoire. Le mémoire vidéo a une grande bande passante mais aussi une grande latence (> 100ns). Les primitives de synchronisation sont maigres et les opérations atomiques prohibitives.

* La communication entre CPU et GPU a une latence énorme (1 à 10ms). On évitera donc de faire des aller-retours de l'un à l'autre et on essaiera autant que possible de rester sur le GPU. De même il faut envoyer un nombre assez grand d'éléments à traiter : solliciter le GPU pour inverser une matrice 4x4 n'aurait aucun sens.

* Il n'y a pas de pile d'appels : on peut déclarer des fonctions mais elles seront inlinées (copier-coller pour former une seule fonction) et la récursion n'est pas supportée. Pas non plus d'exceptions ou autres.

* Il y a beaucoup de registres et tant mieux car il faut compenser la grande latence de la mémoire. Mais du coup tes variables locales sont limitées à ces registres et les emplacements sont comptés (disons 80 - un vecteur 4d en prend 4, une référence vers un tableau en mémoire en prend 1 si je ne m'abuse - à vérifier).

* Le langage à utiliser est spécifique, calqué sur C99, mais plus primitif. Minimise dans la mesure du possible les boucles et surtout les branchements conditionnels (ou essaie de faire en sorte que les résultats soient aussi souvent que possible identiques sur tous les threads). Il n'y a pas de classes et les types de données sont primitifs (vecteurs 2D/3D/4D, matrices 2D/3D, entiers, réels), tout juste peux-tu définie des structures personnalisées (simples séquences de champs).



Si ton programme s'y prête parfaitement, le GPU t'offrira des performances cent fois supérieures. Mais rares sont les problèmes à s'y prêter. Heureusement pour toi les problèmes scientifiques y fonctionnent très bien et nécessitent plus rarement que d'autres des mécanismes de synchronisation tortueux (es-tu au fait de ces problèmes ? sais-tu quel sera le problème avec une incrémentation d'une même valeur effectuée en parallèle par deux threads par exemple ?)

[regis.portalez]

La question est très ancienne, et les réponses aussi.

Pourtant je ne peux pas laisser dire que CUDA est sur le déclin et que la bonne façon de programmer un GPU est OpenCL.



Même AMD (qui était le seul à utiliser sérieusement opencl) a sorti un language proche de CUDA, HIP.

CUDA 1.0 était effectivement une version primitive de C mais les choses se sont beaucoup améliorées depuis 2008. CUDA supporte aujourd'hui les templates et les fonctions virtuelles par exemple.

Comme l'indique DonQuiche, un GPU est cependant différent d'un CPU et ne se programme pas exactement de la même façon.

Les "threads" d'un GPU ne sont pas exactement l'équivalent des threads CPU comme il l'indique (même si ça va commence à changer avec Volta). De même, la mémoire du GPU n'est pas la même que la RAM de l'ordinateur (elle est dans le GPU). Ce sont les deux notions à comprendre pour programmer un GPU, mais on s'y fait vite.

Si tu ne veux pas apprendre C++/CUDA, il existe des produits (libres, open source, commerciaux...) qui permettent d'utiliser C# pour programmer le GPU (nvidia).

Je pense par exemple à

1. Hybridizer. C'est un compilateur propriétaire qui transforme ton code C# en code CUDA. Il existe une version gratuite qui génère un binaire CUDA à la place du code. A noter que les fonctions virtuelles et les génériques sont supportés.
2. ManagedCUDA C'est un simple wrapper CUDA, qui ne t'évitera pas de programmer en C++/CUDA. Cependant tu pourras facilement appeler ce code depuis C#.

[François DORIN]

Bonjour,
C'est surtout aussi que CUDA/OpenCL ont des finalités différentes !

CUDA est effectivement spécifique à NVidia et permet d'exploiter toute leur puissance pour le calcul.

OpenCL est une abstraction, permettant de distribuer des calculs aussi bien sur CPU que GPU. Cela nécessite d'avoir une carte graphique compatible car nécessite des drivers spécifiques.