Discussion :

[Matthieu76]

Bonjour, je suis en train d'apprendre à codé en CUDA et j'ai vu qu'il fallait passer les variables sur le GPU pour effectuer des calculs de mass. (Je développe des réseaux de neurones.)
J'aimerais savoir s'il est plus rapide de passer un tableau à mon GPU ou si passer variable par variable n'augme pas significativement le temps de calcul.

Actuellement j'ai un objet contenant des objets qui contiennent des vectors, es-ce vraiment plus rapide de transformer tout ça en matrice et de faire du calcul matriciel ?

Dites-moi ce que vous en penser

[jo_link_noir]

Quand tu dis "variable par variable", cela veut dire transmettre chaque valeur du tableau l'une après l'autre ? Parce que les GPUs sont prévu pour manipuler un grand nombre de valeur en même temps, donc des tableaux.

Après je ne sais pas à quoi ressemble tes calculs, ni tes données, mais si tu peux envoyer tout d'un coup, c'est préférable. Le coup de transfert n'es pas nul. Tu peux aussi faire une grosse allocation au niveau CUDA et remplir ligne par ligne. Je ne sais pas ce qui est plus performant.

[Matthieu76]

Merci pour ta réponse, je pense que je vais recopier "salement" tous mes vector de vertor d'objet. En gros je vais tout transformer en structures, tableaux et listes chaînées (que je vais devoir ré-implémenter).
Ensuite je vais faire mes calculs puis je vais tout re-transformer en le type de données de départ.
Mes fonction d'initialisation et de récupération de données seront très lourde mais ça à la limite c'est pas trop grave car je devrais pas avoir à les utiliser dans la boucle principale.

C'est compliqué pour moi car même si je développe beaucoup j'ai pas l'habitude d'utiliser des pointeurs, va pas falloir que je me plante dans mes recopies.

[dragonjoker59]

Les listes chaînées, tu en as besoin en tant que listes chainées pour tes calculs ? Parce que niveau exploitation du cache il est difficile de faire pire, donc si tu peux les traiter en tant que tableaux, ce serait tout bénef (pas d'implémentation de liste chainée à débugger, meilleure exploitation du cache, toussa)

[Danny-k]

Avec CUDA (ou n'importe quel API GPU), on travaille toujours en envoyant au maximum des buffers plutôt que variables par variable, le coût de transfert du CPU vers le GPU et vice versa, n'est absolument pas gratuit, voilà pourquoi il est préférable d'arranger ses données et une fois fait on envoie en une fois sur le GPU afin de minimum le taux transfert, et qu'il devienne négligeable par rapport aux gains.
Au lieu de te casser la tête en voulant recopier tes vector d'objets vers des pointeurs, NVidia fournit la lib thrust, qui est le pendant de la STL mais pour GPU NVidia, utilises ça ça te facilitera la vie.

Sinon comme dit plus haut, abandonne les listes, et utilises des vectors, c'est toujours plus performant que des list, plus cache friendly.

[Matthieu76]

merci pour tous vos conseils

Du coup le mieux c'est que je regroupe les variables de mon objet dans une structure puis qu'avec la lib thrust j'envoie directement un vector de cette structure ?

Ou même mieux, une fois que j'ai mit les variables de mon objet dans une structure j'utilise la mémoire partagée pour ces variables.

Je vais me renseigner comment coder tout ça et je vous fait un retour dès que j'aurais du nouveau.


PS : Dans mon objet, j'ai un vector de variable mais de taille fixe, j'avais utilisé un vector à l'époque car c'est beaucoup plus simple pour les copies. Je garde ça en vector du coup, on est d'accord ? Ça augmentera pas mon temps de calcul, si ?

[Matthieu76]

Voilà l'architecture que j'ai choisi pour mon programme, je pense pas utiliser les vertors CUDA car les vectors de mon objet sont de taille fixe pendant les calculs donc des tableaux suffiront.

[Matthieu76]

Actuellement mon code CUDA est en pause, je continue mon projet sur CPU car c'est beaucoup plus rapide à développer et surtout à tester, de plus les autres développeurs avec qui je travaille n'ont pas de GPU Nvidia. Je garde mon code de côté et je le réutiliserais plus tard quand j'en aurait vraiment besoin même si paralléliser sur plusieurs CPU à l'air plus simple et tout autant efficace.