Evolution du GPGPU Computing

Que pouvez-vous nous dire à propos de CUDA en tant qu’architecture par rapport au compilateur CUDA pour C ?

CUDA est l’architecture hardware propre à NVIDIA pour l’informatique parallèle. Nous fournissons un ensemble d’outils pour programmer l’architecture CUDA, parmi lesquels compilateur, débogueur, profiler, librairies ainsi que d’autres informations nécessaires aux développeurs pour arriver à des produits de qualité reposant sur l’architecture CUDA. Cette dernière supporte également les langages standards (C et Fortran avec extensions CUDA dans les deux cas) ainsi que les interfaces de programmation pour le GPU computing comme OpenCL et DirectX.

Voici un diagramme pour y voir plus clair :

OpenCL a l’avantage d’un support multiplateforme, mais on y perd certains outils automatisés propres à CUDA comme la gestion mémoire. On a l’impression qu’en tant que chercheur, vous souhaiteriez baisser les coûts de développement initiaux tout en visant une compatibilité maximale. Comment appréhendez-vous ce défi ?

Il y a bien entendu des compromis à faire pour aboutir à une solution compatible sur plusieurs plateformes/ pour plusieurs fabricants. NVIDIA travaille depuis le début avec Apple et le groupe de travail OpenCL pour assurer une très bonne interface de programmation pour le GPU computing au niveau des pilotes, en particulier pour les produits NVIDIA. En outre, nous allons très certainement créer des extensions supplémentaires pour favoriser l’utilisation d’OpenCL avec les cartes graphiques NVIDIA.

Nous améliorons aussi sans cesse notre compilateur C et l’environnement de développement pour nos produits : quelques extensions simples suffisent à l’utilisation de C sur les cartes graphiques NVIDIA. Si vous préférez Fortran, il y a aussi un compilateur pour l’utiliser. Lorsque Windows 7 sortira, les utilisateurs et développeurs auront accès à l’API DirectCompute, laquelle partage bon nombre de concepts avec nos extensions C. Par ailleurs nous avons fait parvenir un pilote DirectCompute aux principaux développeurs en décembre dernier. Ce sont en somme les avantages liés au choix de composants NVIDIA : nous supportons l’ensemble des langages et interfaces de programmation incontournables.

Vos travaux ont commencé à l’époque du GeForce 5 et de l’eau a coulé sous les ponts depuis. Bien entendu, les produits récents sont beaucoup plus puissants, mais quelles sont plus précisément les capacités qui sont apparues pendant cette période (la compatibilité IEEE-754 par exemple) ? Qu’est-ce qui était impossible à l’époque et faisable aujourd’hui ?

Les premiers GPU programmables n’étaient que des unités de calcul à virgule flottante simplistes. Pas d’entiers ni de bits, pas plus que d’accès général à la mémoire GPU, pas de communication possible avec les processeurs de traitement avoisinants. La première innovation majeure a été de créer les composants nécessaires au support de C, gérant intégralement les pointeurs et types de données natives.

Une autre innovation clé a été l’ajout de mémoire propre au GPU qui, partagée entre les processeurs de traitement, leur permet de communiquer entre eux et d’échanger des résultats, améliorant ainsi l’efficacité des algorithmes. De plus, ceci permettait aux programmeurs de stocker temporairement et traiter des données à proximité des processeurs,  plutôt que de remonter jusqu’à la DRAM. La mémoire commune a eu pour effet d’améliorer la librairie de traitement du signal 20 fois mieux qu’une implémentation OpenGL similaire.

Enfin, l’arrivée de composants capables de calculs à virgule flottante à double précision doit aussi être considérée comme un grand pas en avant pour les GPU, ceux-ci devenant des unités de calcul à haute performances capables de répondre à des besoins d’une précision extrême. Il faut aussi noter les améliorations quant à la fréquence et à la taille de la mémoire embarquée (jusqu’à 4 Go par unité de traitement et 16 Go pour notre serveur Tesla 1U), qui permettent aux GPU NVIDIA d‘affronter des problèmes à plus grande échelle.

Qu’en est-il du compilateur ? Quel genre d’optimisations et d’innovations ont été apportées au fil du temps ?

Nous avons très vite pris conscience de la nécessité d’avoir un compilateur mondialement reconnu : les programmes de GPU computing tendent à être plus lourds, plus complexes et tirent parti d’optimisations plus poussées. Notre concurrent, le CPU, a nécessité presque 40 ans de travail pour comprendre cela. Le compilateur est basé sur les technologies de l’Edison Design Group, qui produit des compilateurs C depuis 20 ans, ainsi que le cœur du compilateur Open64 qui a été conçu pour les processeurs Itanium à la base. Notre technologie alliée à l’équipe de compilateurs de premier plan qui a été réunie sont autant d’éléments clés dans la réussite de NVIDIA.

Pour le moment, la plupart des GPU sont très rapides en mathématiques à simple précision, mais nettement moins lorsqu’il s’agit de double précision. Outre le fait des économies d’échelle liées à la production, les GPU auront-ils encore un rapport prix/performances « meilleur que celui du CPU » à l’avenir ? Concrètement, pourriez-vous faire des GPU spécifiquement optimisés pour la double précision tout en maintenant de faibles coûts de production ?

Vu que le marché du GPU computing est clairement sur la pente ascendante, je pense que vous verrez de plus en plus d’applications aux mathématiques en double précision. Les composants dédiés à la double précision que nous avons commercialisé l’année dernière n’étaient que le point de départ vis-à-vis de ce que je vois comme un investissement croissant dans le GPU computing, aussi bien pour NVIDIA que pour l’industrie en général.

Que pensez-vous de Larabee ? De la Stream Architecture d’AMD ? Du Cell et du Zii ?

Je vois Larabee comme étant d’une part une reconnaissance de ce que le GPU a accompli jusqu’ici, et d’autre part l’acceptation des limites du CPU. Là où les CPU ont essayé de prendre un modèle de programmation séquentiel patrimonial et d’exploiter le moindre bit de parallélisme, les GPU ont été crées pour le rendu 3D dont le parallélisme par nature est évident. Le parallélisme massif est partie intégrante du modèle de programmation élémentaire du GPU.

Au final, ce sont l’accessibilité et la productivité d’un modèle de programmation qui font passer une architecture du stade de nouveauté à un succès. On se bat tous contre une montagne de code patrimonial, désuet. Le but est de permettre très facilement aux GPU NVIDIA des gains de performances majeurs à l’aide d’un modèle de programmation aussi simple que familier.