ou INSCRIVEZ-VOUS Mot de passe oublié ?
Publicité

Interview exclusive : tout sur le supercalculateur GPU français

Bruno Cormier le 16 juin 2008 (34 760 lectures)
Le GPU s'annonce donc comme une évolution majeure dans le domaine technique du calcul intensif, mais quels handicaps possède-t-il encore face aux CPU ?

Il y en a tout de même beaucoup. L'avenir réside, comme certains le prétendent peut-être, dans le GPU, mais il faut être un peu plus mitigé. Jusqu'à maintenant, le GPU ne supporte pas efficacement la double précision, ni la correction d'erreur au niveau de sa mémoire graphique, et il est encore “loin” du processeur (mais cela changera bientôt).

Le GPU pêche aussi au niveau de l'intégration totale de la norme IEEE 754, essentielle dans les calculs à virgule flottante, notamment au niveau des arrondis, des underflow, des overflow, qui ne sont pas encore totalement traités par les GPU. Le « gamer » n'en a pas besoin, mais le scientifique oui.

(NDLR : On sait maintenant que le Tesla T10P (GT200) de NVIDIA supporte la norme IEEE 754 pour le calcul en virgule flottante)

Tesla GPU T10P

CUDA par exemple, c'est déjà bien, mais pas totalement complet, notamment pour le debugging ou le profiling. Les gens qui développent ce type d'applications sur les processeurs traditionnels attendront qu'il y ait un gros marché pour les transposer sur GPU. De même, sur CPU, on peut faire tourner une très grande variété de logiciels, notamment certains codes commerciaux, qui ne sont pas encore développés pour GPU.

Il y a toujours ce problème du GPU qui est finalement assez éloigné du processeur, et qui n'a pas toujours assez de mémoire pour traiter un problème en entier. Le GPU pourra alors traiter seulement des bouts de code préparés, ou des codes qui entrent dans ses 4 Go de mémoire. Le modèle qu'on imagine est donc encore un modèle où le GPU reste un coprocesseur du CPU. Cela viendra sûrement, mais pour l'instant, il y a encore très peu de codes qui sont entièrement mis sur GPU, parce que beaucoup d'entre eux nécessitent quelque dizaines de Go (voire plus) de mémoire vive et que les coûts des transferts de données sont élevés et pas toujours algorithmiquement recouvrables par du calcul.


Si je comprends bien, la quantité de mémoire semble être un handicap sérieux ?

Par exemple, les Tesla du CCRT disposeront de 4 GPU qui communiquent très rapidement avec leur propre mémoire vive graphique sur une bande passante énorme. Mais la bande passante PCI-Express 2.0 risque d'être un goulet d'étranglement important face à la puissance de traitement des GPU, dès qu'il faudra aller chercher des données en mémoire centrale (les 25 To de RAM des CPU, NDLR).

Il faudra donc bien fragmenter les codes pour optimiser les calculs en évitant un maximum d'accès entre les GPU et la mémoire vive centrale, mais le nerf de la guerre c'est surtout de rapprocher le CPU du GPU.

L'idée d'avenir, c'est que sur la même carte mère, ou dans un même processeur, le CPU et le GPU puissent accéder directement à la mémoire centrale sur un bus très rapide. C'est ce que prépare Intel avec le projet Larrabee, et AMD avec le projet Fusion. Les débits seront ainsi largement supérieurs à ceux du PCI-Express, le gain sera majeur en termes de calcul intensif. Ces aspects sont très importants pour nous...

L'avantage du GPU reste tout de même la rapidité de ses échanges avec sa propre mémoire dédiée. La bande passante entre un GPU et sa RAM est de l'ordre de 100 Go/s, ce qu'on est loin d'avoir avec un CPU sur un bus normal (HyperTransport d'AMD, ou QPI chez Intel). Ce sont des débits de mémoire très proches de ceux des machines vectorielles qu'on connaissait autrefois. C'est pour ça qu'avec un code bien optimisé, le gain de performances est énorme, de facteur 20 ou même 100.

Stéphane Requena, merci pour toutes ces réponses !