Rendez-vous avec Sumit GUPTA,
Directeur Général de l’activité Tesla, NVIDIA

Propos recueillis par Frédéric MILLIOT

Commençons par une question toute simple, qui concerne en réalité moins l’aspect business que l’aspect standardisation technologique : quelle est la part de marché du GPU dans le monde HPC aujourd’hui ?

Si vous regardez bien, l’arrivée de l’accélération GPU dans le monde HPC est assez récente. De ce fait, son poids reste encore assez limité. Mais les choses évoluent vite et le succès de certaines implémentations en appelle d’autres. Il va falloir encore probablement deux bonnes années pour que le GPU pénètre véritablement tous les domaines du HPC. Pourquoi ? Parce que certaines applications très largement utilisées n’ont pas encore été déclinées en version « GPU-accelerated ». Je parle ici d’applications purement HPC. D’un autre côté, d’autres applications, beaucoup plus grand public mais liées à des problématiques connexes au HPC telles que le Big Data, par exemple, adoptent l’accélération GPU de façon croissante. Je parle ici de produits ou de services comme Shazam, Twitter, de nombreuses applications vidéo, etc. Ces exemples montrent que l’accélération GPU dépasse le pur périmètre HPC pour faire une entrée en force dans le monde de l’entreprise. Le concept et sa pertinence étant de plus en plus largement compris et accepté, sa part de marché croît de façon réellement exponentielle. Il n’y a qu’à regarder l’évolution récente du Top500. On estime qu’aujourd’hui, 20 % des FLOPs du Top500 sont d’origine GPU. Voilà qui résume assez bien les choses…

Et à horizon 2-3 ans, comment la voyez-vous évoluer ?

Vous voyez, la meilleure réponse que je puisse vous faire est que, bien que je sois responsable de l’ensemble de la gamme Tesla, le HPC n’est plus mon seul marché cible… En d’autres termes, l’accélération GPU étant en train de se généraliser, sa prévalence dans le monde HPC devrait s’accélérer. D’autant que le terme HPC ne se limite plus aujourd’hui au périmètre du serveur. Il y a la station de travail, bien sûr, mais aussi tout un ensemble d’appareils – les scanners médicaux, par exemple – qui sont de véritables stations HPC. Les « CAT scans », aujourd’hui, sont quasiment tous passés du FPGA à l’accélération GPU.

Donc, on peut penser que l’activité Tesla, chez NVIDIA, est profitable ?

Je ne peux pas m’exprimer d’un point de vue purement financier, mais je vous répondrai ceci : Tesla est pour nous crucial, c’est une activité plus que stratégique. Nous investissons énormément dans Tesla et, au risque de vous surprendre, plus encore dans le logiciel que dans le matériel. Les pilotes, les compilateurs, les débogueurs, les bibliothèques CUDA, sans compter les développements communs que nous réalisons avec les éditeurs logiciels (Dassault Systèmes, par exemple)… tout cela représente énormément d’argent. Pensez, par ailleurs, à l’effort que représente la possibilité d’utiliser le même paradigme de développement sur l’intégralité de notre gamme, processeurs mobiles y compris. La conclusion qui s’impose est que si cette activité n’est pas encore totalement profitable, du fait de l’importance de l’investissement initial, les perspectives sont plus que prometteuses, ce qui garantit la pérennité de cette technologie.

Quelle est à votre avis la proportion de codes sources parallèles par rapport au nombre de codes sources séquentiels aujourd’hui ?

La plupart des codes sources exécutés par les supercalculateurs aujourd’hui sont des codes parallèles. Je pense qu’on peut même dire que tous sont parallélisés d’une façon ou d’une autre. En revanche, encore très peu de ces applications sont multi-threadées de façon à ce que chaque thread puisse être accélérée individuellement. Le protocole d’échange de messages qui a longtemps prévalu n’est à l’évidence pas le plus efficace. Et c’est pourquoi, une fois affinée, la même application peut se révéler jusqu’à 10 fois plus rapide en étant exécutée sur plusieurs centaines de nœuds GPU que sur plusieurs milliers de cœurs CPU. Certes, ce changement de paradigme prend du temps et représente de réels investissements, mais l’immense majorité des gens à qui je parle ont d’ores et déjà accepté cette idée. Si bien que, la proportion des codes parallèles va évoluer plutôt qualitativement que quantitativement.

AMD défend depuis longtemps l’idée d’un “APU” incluant CPU et GPU dans le même module, ce qui évidemment a pour bénéfice d’éliminer beaucoup de goulets d’étranglement, de diminuer le coût de l’ensemble, d’augmenter son efficacité énergétique et de faciliter l’intégration en nombre dans de très gros clusters. Quelle est votre position sur ce sujet ?

Vous avez raison, AMD défend cette idée depuis longtemps. Et très franchement, ils ont mille fois raison. Cela posé, en parler, c’est bien, le faire, c’est mieux. Qui a été le premier fondeur à proposer de tels “APU” ? Nous, avec Tegra 1, il y a quasiment 5 ans de cela. Ensuite, Intel s’y est mis aussi pour les processeurs desktop… Maintenant, le concept CPU + GPU dans la même puce n’a pour nous de sens que pour les implémentations d’entrée de gamme. Parce que cette intégration a des inconvénients qui ne sont pas toujours bien perçus. D’abord, il y a le délai d’intégration. Prenez Kepler par exemple. Kepler, en implémentation autonome, était disponible l’année dernière. Or, elle ne sera intégrée au CPU Tegra Logan que dans environ 9 à 12 mois. C’est un délai qui peut s’avérer inacceptable dans nombre de cas. Deuxième problème, l’allocation des ressources entre CPU et GPU en termes d’espace physique dans le module. Quel peut être le meilleur arbitrage, le meilleur compromis ? C’est une question à laquelle il n’existe pas, selon nous, de bonne réponse par rapport à des implémentations de type CPU toutes options + GPU toutes options. Enfin, n’oublions pas que CPU et GPU ont besoin de mémoires différentes, et en nature et en taille. Au bout du compte, on reste bel et bien avec deux systèmes séparés, même s’ils sont intégrés dans la même enveloppe. On élimine dans une certaine mesure le goulet du bus PCIe, mais on se crée d’autres contraintes, électroniques et logiques, à notre sens contraires aux attentes du monde HPC en termes de résultats effectifs.

Dans le même ordre d’idée, à quand les communications directes entre processeurs et unités de stockage ?

Clairement, il faudrait développer une nouvelle génération de bus, type PCIe génération 4, mais la chose risque de prendre du temps, dans la mesure où cette initiative concerne l’ensemble de l’industrie. Il est clair qu’on va vite avoir besoin d’une nouvelle voie de communication pour les données avant et après leur traitement par le « processeur » (quelle que soit sa nature). Dans l’architecture Kepler, NVIDIA a fait un pas en avant avec GPUDirect, qui permet d’implémenter InfiniBand en mode RDMA [Remote Direct Memory Access – ndlR]. La même technique pourrait être appliquée pour le dialogue direct avec une unité de stockage ou d’acquisition de données. Après tout, un GPU est un processeur de traitement de données alors pourquoi ces données devraient elles auparavant passer par la mémoire système ? Je peux vous dire que nous y réfléchissons très sérieusement. Et même si nous prenons l’initiative de notre seul côté, il est probable que les utilisateurs de solutions NVIDIA nous suivront sur ce terrain.

A ce propos, si j’opte pour votre nouvelle solution Grid VCA en mode octo-GPU, les huit connecteurs PCIe vont être occupés. Comment puis-je alors communiquer avec le reste de mon cluster, ou avec d’autres unités Grid VCA si je les empile ?

Il y a un connecteur Ethernet intégré au châssis, indépendant de la connectique PCIe. Donc on a toujours l’opportunité d’une connexion réseau standard.

Mais alors, on reste en GpbE ? Pas de 10 GbpE ni d’InfiniBand ?

Non. Mais vous savez, Grid VCA est plutôt dédié aux utilisations VDI, qui n’ont que très rarement besoin d’InfiniBand.

Autre point qui fait polémique, les GPU de la génération Kepler semblent mal fonctionner en mode PCIe 3.0, d’où le fait que le pilote force l’ensemble à fonctionner en mode PCIe 2.0. Avez-vous résolu le problème ?

(rires…) Il y a confusion dans ce domaine. Nous n’avons jamais revendiqué le fonctionnement de Kepler en PCIe 3.0. Kepler est spécifié officiellement pour PCIe 2.0. Et ce pour une raison simple : Sandy Bridge fonctionne mal avec PCIe 3.0. D’ailleurs, Xeon Phi lui-même est PCIe 2.0, parce qu’Intel n’a pas pu faire le fonctionner correctement en mode PCIe 3.0. Si j’ose dire, ce n’est pas Kepler qui fonctionne mal avec PCIe 3.0, c’est PCIe 3.0 qui fonctionne mal avec nos produits – et avec de nombreux autres dont, comme je disais, ceux d’Intel.

Parlons maintenant d’OpenACC. Ma question est complexe, je vais essayer de vous la poser clairement. Aujourd’hui, grâce aux fonctions internes de Kepler (parallélisme dynamique, hyper-Q, etc.), une fois que les données ont été transférées au GPU, c’est lui qui s’occupe de tout. De sorte qu’à ce stade, le développeur n’a plus vraiment le contrôle sur ce qui se passe. D’après vos annonces, les générations d’accélérateurs GPU à venir vont renforcer cette autonomie. Dans cette mesure, l’affinage du code source via CUDA va-t-il rester réellement pertinent, en termes d’investissement de temps et de compétences, par rapport à un « simple » passage par
OpenACC ?

Effectivement, ces fonctionnalités sont très utiles avec OpenACC, notamment le parallélisme dynamique. Le gain en efficacité est énorme. En revanche, il existe une corrélation forte entre la puissance d’OpenACC et le degré de parallélisme du code sur lequel les directives sont appliquées. Trop de pointeurs, trop d’aliasing, et le compilateur est à la peine. On ne peut pas faire l’économie d’un minimum de préparation des sources avant d’obtenir de bons résultats avec OpenACC. Ces prérequis étant établis, je vais vous faire une confidence : je souhaite que tous les utilisateurs de GPU NVIDIA utilisent également OpenACC. Qu’ils obtiennent très rapidement et le plus facilement possible une accélération maximale de leur application. Et qu’ensuite, après avoir identifié le ou les kernels les plus critiques, ils prennent le temps de les affiner en CUDA. L’approche mixte CUDA + OpenACC est sans doute la plus productive dans la majorité des contextes applicatifs. Bien sûr, les progrès des deux compilateurs et les habitudes des développeurs sont tels qu’il restera toujours des applications 100 % CUDA et d’autres 100 % OpenACC. Mais à mesure qu’OpenACC avance, ses bénéfices immédiats sont de plus en plus reconnus. Le gain en performance qui découle de l’application de la bonne directive au bon endroit a quelque chose d’addictif. Et, naturellement, les travaux de recherche ou de simulation qui constituent la finalité du code en bénéficient tout autant. Quand on peut exécuter la même application dix fois au lieu d’une fois par jour, on gagne en complétude, on gagne en perspective. Enfin, quand des considérations industrielles sont en jeu, les économies potentielles peuvent être considérables. Dans l’automobile par exemple, la multiplication des crash tests virtuels, en complément des tests réels, aboutit non seulement à des voitures bien plus sûres, mais également à des économies de matériaux, donc à des voitures moins chères à produire, plus légères, moins gourmandes et moins polluantes. C’est un effet boule de neige qu’on retrouve dans un très grand nombre de secteurs d’activité.

Dernière question, vous avez annoncé il y a deux jours GTX Titan, une carte graphique de très haut de gamme architecturée autour du processeur GK110, le même que dans Kepler K20, et embarquant 6 Go de GDDR5. Doit-on la considérer comme un produit de jeu ou comme un accélérateur GPU d’entrée de gamme ?

Les deux ! C’est aujourd’hui la meilleure carte graphique du marché, mais également le meilleur accélérateur GPU en termes de rapport qualité/prix. Vous souhaitez commencer à développer en CUDA ? Tout CUDA est dans cette carte, qui coûtera moins de 1000 dollars ici aux Etats-Unis. Vous souhaitez développer pour Xeon Phi ? Vous devrez d’abord dépenser 2 à 3000 USD. Parce que le code Xeon Phi est spécifique à Xeon Phi. Il ne tourne pas sur le ou les Xeon dont vous disposez peut-être déjà. Alors que votre code CUDA s’exécute partout, y compris sur votre PC portable pour peu qu’il soit équipé d’un GPU NVIDIA même d’entrée de gamme. En d’autres termes, nous offrons aux développeurs une multitude d’environnements de développement CUDA, dont certains très accessibles financièrement. Ensuite, libre à chacun de choisir l’accélérateur GPU le plus approprié pour la mise en production de l’application.

Et vos revendeurs spécialisés Tesla, comment réagissent-ils ?

Certes, la sortie de ce produit empiète sur leur territoire commercial, et je ne nie pas qu’il y a là un vrai challenge pour eux, au moins temporairement. Mais s’ils nous ont fait confiance en associant une part de leur destin au nôtre, c’est parce qu’ils croient comme nous en l’avenir de cette technologie. GTX Titan va faire venir à CUDA et à l’accélération GPU un grand nombre de nouveaux utilisateurs. Et je ne crois pas que le monde du HPC tel qu’il existe aujourd’hui préférera GTX Titan à nos accélérateurs Kepler K10 ou K20. C’est une stratégie de développement, voire de standardisation, à long terme. A ce titre, je suis convaincu que tout le monde en profitera, à commencer par les chercheurs et ingénieurs qui ont fait, ou s’apprêtent à faire, le choix de l’accélération GPU.