(quote:48563:Perfect Slayer)
Ça serait sympa d’avoir un retour de ceux qui utilisent ce genre de techno pour savoir ce qu’ils en pensent de toutes ces API et de l’intérêt / coût du passage de l’une à l’autre :)

Pour la faire courte : Pourquoi faire ? il existe autre chose que CUDA ?

Oui, comme dit dans l’article, NVidia et largement dominant dans le domaine du calcule sur GPU (et avec les carte RTX, les TensorCore sont presque des ASIC dédié uniquement au produit matriciel). La dessus, NVidia arrive à s’imposer avec ses solutions matérielles mais aussi logicielles. OpenCL n’a jamais décollé et ROCm semble aussi prendre la même voie. Du coup, dans le domaine du calcule scientifique, les solutions intègre généralement uniquement le support de CUDA, tout le reste passe au second plan. Au niveau des grilles de calculs, c’est la même chose, on ne trouve que des cartes graphique NVidia.

Magyar a dit:

Je suis pas sur de comprendre la phrase : “L’objectif est ainsi de fournir un ensemble d’outils permettant de compiler du code C(++) ou Fortran parallélisé pour qu’il tire parti du GPU et pas seulement du CPU.”. On pourra compiler son code C/C++ avec son GPU en plus du CPU ? Ou alors il sera possible de faire du code qui exploitent des ressources, peu importe que ça soit un CPU ou GPU ?

La seconde. La première me parrait pas terrible : je ne pense pas qu’il soit possible de réellement accélérer la compilation en utilisant du GPU, je ne vois pas trop comment on peut transformer la compilation en calculs matriciels.

Non, le but est d’avoir un code agnostique du matériel. En effet, tu n’a pas forcément un GPU Nvidia avec CUDA d’installer et sur CPU, tu peux tirer partie des instruction SSE/AVX pour avantageusement remplacer le calcul sur GPU. Mais je suis assez curieux de voir à quel point c’est transparent et bien optimisé. Dans le genre, il existe Numba en python qui semble faire quelque chose de similaire, mais ce n’est pas 100% transparent.

Magyar a dit:

Ok, merci pour la réponse

Pour te donner une analogie de la différence entre un CPU et un GPU, j’utilise souvent l’exemple de la différence enrte une équipe de recherche avec quelques couples directeur de thèse et son doctorant et collège avec un prof et plein d’élève.

Dans une équipe de recherche tu as quelque couples directeurs de thèse doctorant. Le directeur de thèse va donner des instructions à son doctorant que ce dernier va réaliser une a une. Ca permet de faire des instruction complexe, mais le doctorant n’est capable de faire qu’une instruction que sur une donnée à la fois. S’il doit faire la somme de deux table pair à pair, il devra faire ligne par ligne l’une après l’autre. C’est l’équivalent d’1 seul cœur dans un CPU. Aujourd’hui on a des PC multicœurs, mais c’est grossièrement la même chose.

Cependant, à coté, tu as le collège, qui est composé de plusieurs classe contenant 1 prof et des dixaines d’élèves (64 sur un architecture Ampère). Le prof ne peut donner qu’une seul instruction à l’ensemble de sa classe, cependant il peut demander à chaque élève de travailler sur une position différente d’un tableaux. Du coup, dans le cas d’une addition de 2 tables, s’il y a 64 élève dans la classe, les opération se feront par lot de 64. Cependant, on reste au collèges, et tu ne t’attends pas forcément à faire des truc complexe il faut que les instruction soit simple et claire (les condition, les boucles… tout ce qui est branchement dans le code, le GPU n’aime pas trop ça.).

Au niveau de la programmation, le paradigme est assez différent à la base entre CPU et GPU. Autant sur CPU, tu vas facilement faire des embranchement, des boucles, des conditions…. Et si tu veux parallèliser, chaque exécution parallèle sur chaque cœur va être fait de manière indépendante des autre, et pourra avoir donc suivre sa propre suite d’instruction. Autant sur GPU, le paradigme et plutôt de penser comme une suite sans embranchement de manipulation de donnée dans des tables. Le parallélisme ici est surtout dû au fait que chaque opération travaille directement sur des tables.
La façon de penser est très différente. C’est assez déroutant parfois de devoir se contraindre à manipuler les données dans des tables (des tenseurs) lors qu’il aurait été tellement simple de faire une boucle où une condition, et devoir jouer avec le broadcast et l’ajout de dimension. Typiquement si tu as 2 vecteurs, et tu souhaite faire une table de multiplication des 2 tu devrais faire un truc dans le genre :

sur CPU de manière classique :

#on va utiliser la bibliothèque numpy pour  manipuler des table multidimensionnelles. Même si ça ne fonctionne que sur CPU, c'est un très bon exemple. 
import numpy as np
#v1 et v1 seront mes 2 vecteurs, ici je fais une simple table de multiplication de1 jusqu'à 10
v1=np.arange(10)+1 #V1== [1,2,..., 9,10], le '+1' s’appliquant à l'intégralité du vecteur grâce au broadcast.
v2=np.arange(10)+1
t=np.empty((len(v1), len(v2))) #t : table vide de 10*10
for i, vv1 in enumerate(v1):
    for j, vv2 in enumerate(v2):
        t[i,j]=vv1*vv2
print(t)
#[[  1   2   3   4   5   6   7   8   9  10]
# [  2   4   6   8  10  12  14  16  18  20]
# ...
# [ 10  20  30  40  50  60  70  80  90 100]]

Voici une version plus “GPU” friendly :

import numpy as np
v1=np.arange(10)+1 
v2=np.arange(10)+1
v2p=v2[...,np.newaxis] 
#v2p==[[1], [2],..., [9], [10]], v2p est un matrice de 10*1. Cette façon de faire est très "numpyesque". 
t=v1*v2p 
# magie du broadcast à nouveau: une opération entre un table de dimension (10) et une autre (1,10) produit une sortie (10,10) en répétant virtuellement les entrées pour correspondre à cette dimension de sortie. 
print(t)

Pour cette dernière partie, j’ai un peu moins de connaissances, mais a priori, sur un GPU, ça va même plus loin les “classe” travaillent en flux continue (CUDA Dynamic Parallelism). Dans l’analogie, si la 6ième B travaille sur les résultats calculés par la 6ième A, la 6ième A ne va pas attendre d’avoir fini de calculer l’intégralité de leur résultat pour les donner à la 6ième B, mais va les donner au fur et a mesure que c’est calculé. Ca n’attend pas que les entrées soient totalement calculées pour commencer à travailler dessus, ça consomme dès que c’est disponible. Du coup, les GPU sont extrêmement efficace lorsque tu enchaînes plusieurs calculs.