Au cours de la conférence Super Computing 2019, NVIDIA et Microsoft ont annoncé leur collaboration dans la solution infonuagique de Microsoft, Azure, pour proposer une offre orientée calcul de haute performance. Les instances proposées, nommées NDv2, disposent toutes de cartes graphiques NVIDIA V100, particulièrement bien prévues pour l’entraînement de réseaux neuronaux profonds.
Le déploiement dans les centres informatiques de Microsoft présente une taille assez importante : on compte pas moins de huit cents cartes graphiques disponibles, sur des machines toutes reliées par un réseau Mellanox InfiniBand (huit cartes par machine). L’objectif est de faciliter l’accès à la puissance de calcul nécessaire pour les applications actuelles en calcul de haute performance et en apprentissage automatique à base de réseaux neuronaux : d’habitude, l’investissement nécessaire pour ce genre d’équipement dépasse le budget de bon nombre d’entreprises. Une infrastructure infonuagique peut représenter un moyen de se lancer avec moins de moyens financiers.
Cette solution est prévue pour surtout des applications d’entraînement de réseaux neuronaux. Lors de leurs tests, NVIDIA et Microsoft sont montés jusque soixante-quatre instances NDv2 pour un modèle BERT, dont l’entraînement a été terminé en trois heures. L’autre grand scénario d’utilisation prévu est le calcul scientifique, avec des logiciels comme LAMMPS (dynamique moléculaire) : on peut monter à des centaines d’instances avec une mise à l’échelle linéaire.
Les premiers signes sont apparus dans des contributions au noyau Linux, avant d’être explicités. Intel travaille actuellement sur DSA, data streaming accelerator, la prochaine génération de sa technologie QuickData. L’objectif est d’échanger très rapidement des données entre le processeur et un accélérateur (stockage, réseau, mémoire, traitement de données) : cette technologie pourra s’occuper de l’échange de données et de certaines transformations (comme un calcul d’une somme de contrôle CRC), sans nécessiter de cycle sur un cœur de calcul. La virtualisation est prise en compte dès le départ, à travers IOV. On pourrait la voir arriver dès la génération Sapphire Rapids de processeurs Xeon, c’est-à-dire dès 2021.
Le module DSA dispose d’une série de files, où les requêtes sont stockées. Ce module est aussi constitué d’une série de moteurs d’exécution, chargés de traiter ces requêtes (potentiellement en parallèle, donc). Des moteurs d’exécution peuvent être groupés, selon les besoins : de fait, les files peuvent être réservées à un seul client ou bien partagées entre plusieurs. D’un point de vue technique, l’instruction MOVDIR64B permet de transmettre la description des tâches à effectuer (sans dépasser la longueur des files, fixée au niveau matériel, sans quoi certaines tâches devraient être abandonnées) ; ENQCMD (mode utilisateur) et ENQCMDS (mode noyau/superviseur) permettent de poster une demande dans une file donnée.
Comme tout système complexe, DSA a aussi besoin de la collaboration du noyau (Linux ou Windows, a priori). Celle-ci se passe à travers le pilote IDXD (Intel data accelerator driver), qui peut exposer les files configurées aux applications utilisateur. Elles sont décrites par des VDCM (virtual device composition module), de telle sorte qu’une application virtualisée puisse également bénéficier de la technologie.
On en parle depuis des lustres, voici le temps des officialisations. Les cartes graphiques Intel Xe ont commencé comme des rumeurs, puis ont été annoncées en juin 2018. Depuis lors, les détails réels et officiels n’ont pas été nombreux. Certaines rumeurs, comme la présence de mémoire HBM sur toutes les cartes, se sont révélées fausses par la suite…
Intel prévoit trois gammes de cartes. Les Xe LP (low power) sont prévues comme cartes intégrées ou d’entrée de gamme, avec une consommation énergétique entre cinq et vingt watts (mais possiblement jusque cinquante). Les Xe HP (high performance) sont prévues comme les cartes principales pour les joueurs, les centres informatiques et les applications d'”intelligence artificielle”, avec une puissance entre septante-cinq et deux cent cinquante watts. La troisième gamme, Xe HPC, vise les superordinateurs, avec une performance en calcul bien plus élevée : ces processeurs pourront monter à plusieurs milliers d’unités d’exécution (chacune pouvant effectuer des calculs en virgule flottante jusque quarante fois plus vite que les unités actuelles — qui ne visent pas du tout le même marché).
Ces processeurs graphiques seront programmables selon trois modes : SIMD, comme les CPU actuels (une seule instruction opère sur une série de valeurs à la fois), avec des instructions comme SSE ou AVX ; SIMT, comme les GPU actuels (une seule instruction opère sur un grand nombre de valeurs à la fois dans des fils d’exécution séparés) ; SIMD et SIMT, pour une performance maximale. En pratique, ces processeurs graphiques peuvent fonctionner sur des vecteurs de taille très variable, ce qui mène à la distinction entre SIMD et SIMT.
L’architecture mémoire des processeurs graphiques est entièrement revue, pour être utilisable à toutes les échelles où les processeurs Xe seront disponibles. Elle porte le nom de XeMF (Xe memory fabric) et peut se connecter à une série de canaux de mémoire à haute bande passante (de type HBM).
Aussi, ces processeurs disposeront d’un énorme cache (en nombre de bits stockables et en millimètres carrés sur le processeur). Rambo sera unifié, c’est-à-dire accessible tant par le CPU que le GPU : il devrait aussi servir à la communication entre processeurs graphiques. Son objectif principal est de fournir une énorme bande passante pour servir autant que possible les unités de calcul en nombres (FP64, surtout). Il ne devrait pas être une limite pour les diverses applications des GPU.
Au niveau matériel, ce cache Rambo devrait correspondre à une puce intégrée dans le boîtier à l’aide de la technologie Foveros : plusieurs puces graphiques seront interposées dans le même boîtier et liées au même cache, pour faciliter les communications (au moins pour la déclinaison HPC).
Le premier GPU à destination des superordinateurs sera le Ponte Vecchio, fabriqué sur le processus en 7 nm d’Intel (qui suit le 10 nm, en cours de déploiement). Il contiendra seize pucettes de calcul sur une même puce, avec d’énormes quantités de HBM.
L’utilisation prévue de ce monstre de puissance, pour le superordinateur Aurora (États-Unis), sera dans des nœuds comportant deux processeurs Intel Xeon de génération Sapphire Rapids (avec des cœurs Willow Cove), plus six processeurs graphiques Ponte Vecchio. Chaque processeur pourra communiquer directement avec les sept autres du même nœud, ce qui garantit une faible latence et une haute bande passante.
libcu++ est une implémentation bibliothèque standard C++ en parallèle (une nouveauté ajoutée avec C++17), ce qui permet d’utiliser les algorithmes de la bibliothèque standard avec la syntaxe habituelle du C++.
Cette version apporte également une nouvelle couche d’interopérabilité à destination de son système d’exploitation en temps réel (RTOS) pour l’automobile NVIDIA DRIVE OS, appelée NVIDIA Software Communication Interface Interoperability (NVSCI). Deux interfaces principales sont disponibles : NvSciBuf pour l’échange de zones de mémoire complètes et NvSciSync pour la synchronisation. Ces fonctionnalités sont en préversion.
Au niveau des plateformes gérées, CUDA 10.2 est la dernière version qui sera disponible pour macOS : on ne devrait donc pas voir de sitôt de nouvelles cartes graphiques pour les ordinateurs de bureau Apple… RHEL 6 n’est plus une distribution Linux approuvée, elle ne sera plus du tout gérée dès la prochaine version de CUDA (tout comme les compilateurs Microsoft C++ 2010 à 2013). Sinon, de nouvelles distributions font leur apparition, voici la liste complète des distributions avec lesquelles CUDA est compatible : RHEL 7 et 8, Fedora 29, OpenSUSE 15, SUSE SLEC 12.4 et 15, Ubuntu 16.04.6 LTS et 18.04.3 LTS.
NVIDIA prépare aussi un petit tri dans les fonctionnalités disponibles. Maintenant que nvJPEG est une bibliothèque à part, les fonctions correspondantes des NPP Compression Primitives s’apprêtent à disparaître. La gestion des plus vieux GPU atteint son crépuscule : les SM 3.0 à 5.2 ne seront bientôt plus gérés ; les SM 3.0 ne le seront plus dès la prochaine version. Il s’agit des architectures Kepler et Maxwell.
Khronos est un regroupement d’industriels qui publie notamment les normes OpenGL et Vulkan, entre autres. Le dernier projet en date semble être une API prévue pour la visualisation de données. Elle se montrerait utile dans la plupart des sciences, où la visualisation des résultats expérimentaux est cruciale (ci-dessous, l’écoulement de l’air autour d’une moto et la molécule antivirale oseltamivir liée à la grippe porcine), mais aussi en science des données.
Pour le moment, les solutions de visualisation sont directement implémentées par-dessus des API de rendu comme OpenGL, Vulkan ou DirectX ou bien sur des bibliothèques de rendu plus spécifiques, notamment à base de lancer de rayons (comme NVIDIA VisRTX et Intel OSPray). Par conséquent, toute solution de visualisation doit définir un grand nombre de primitives très semblables : cela augmente les coûts de développement de ces solutions, mais aussi peut limiter leur performance, à cause du grand écart d’abstraction entre ces API et les tâches de visualisation.
L’objectif de la nouvelle API, prévue pour le “rendu analytique”, serait donc de s’installer entre les solutions de visualisation existantes et les API de rendu, sans toutefois limiter les possibilités des solutions de visualisation et mener à une trop grande uniformisation. Au contraire, cette API devrait faciliter le développement de nouvelles techniques de visualisation en libérant leurs concepteurs des détails de bas niveau liés au rendu. L’implémentation pourrait alors être partagée par de nombreux acteurs et pourrait être de bien meilleure qualité. Cette API pourrait être implémentée par les fournisseurs des bibliothèques de rendu : pilotes graphiques, bibliothèques comme VisRTX ou OSPray, etc.
L’idée actuelle serait de baser cette API sur un graphe de scène : on ne devrait ainsi pas spécifier comment effectuer le rendu, mais “simplement” décrire les relations entre objets dans la scène. L’implémentation de cette API se chargerait alors de déterminer la meilleure manière d’effectuer le rendu souhaité. Il ne devrait pas s’agir d’un graphe de scène trop générique (l’objectif n’est pas de faciliter le développement de jeux, par exemple), mais bien adapté aux spécificités du monde de la visualisation.
La 5G promet d’être une révolution dans les réseaux mobiles. Certains voient l’opportunité d’améliorer les débits grâce à une interface physique améliorée, notamment avec l’utilisation des ondes millimétriques, bien qu’à courte portée. La latence pourrait être réduite d’un facteur dix, la bande passante dans le meilleur cas multipliée par mille, le nombre de clients par kilomètre carré multiplié par plusieurs millions.
D’autres lorgnent du côté de la virtualisation du réseau. En effet, l’un des avantages de la 5G est que chaque composant sera virtualisé, ce qui suit la tendance actuelle dans les centres informatiques : à part l’antenne physique, tous les composants d’un réseau 5G peuvent être répartis sur des machines virtuelles, hébergées n’importe où dans le monde. Par exemple, dans un centre informatique, tout peut être virtualisé, à part la connexion au réseau extérieur : chaque composant d’une application (base de données, serveur applicatif, etc.), mais aussi les parties réseau (répartition de charge, routage, etc.), ce qui est couramment dénommé par l’acronyme SDN (software-defined network).
L’une des possibilités est alors qu’un opérateur peut louer des parties de son réseau à d’autres (des “tranches”, slices), de telle sorte qu’une société pourrait louer toute une infrastructure 5G dans une zone donnée (des champs, par exemple) et traiter les paquets de son côté, ou bien ne louer que l’accès à l’antenne physique et gérer toute la partie depuis le décodage des signaux électromagnétiques elle-même, ou n’importe quelle partie entre les deux. On parle alors de SDR (software-defined radio), la virtualisation pouvant être adaptée en temps réel, en quelques millisecondes (c’est là tout l’avantage par rapport à l’organisation actuelle des réseaux). Chaque composant virtualisé est dénommé fonction virtuelle (NVF). C’est une révolution dans les réseaux, une de plus (après le numérique dans la 2G et les réseaux IP dans la 4G).
NVIDIA vient d’annoncer son arrivée dans le domaine du SDR, avec ses cartes graphiques et sa technologie de calcul sur cartes graphiques CUDA. Quel est le rapport ? À cause de la virtualisation, le matériel actuel ne sera plus adapté : le degré de flexibilité requis sera tellement élevé que les fonctions fixes actuelles ne pourront pas servir tous les cas de figure. Il faudra donc un matériel générique (et très rapide à mettre à jour) qui peut traiter un très grand nombre de paquets par seconde. Les FPGA ne sont pas forcément les plus adaptés, vu qu’il faut un peu de temps pour leur mise à jour (quelques secondes), mais ils seraient tout à fait acceptables. Les cartes graphiques (GPU) peuvent changer de programme à exécuter en quelques millisecondes (le temps d’envoyer le programme sur le processeur).
D’où la solution Aerial de NVIDIA, orientée 5G et virtualisation. Elle comprend deux bibliothèques. cuVNF se focalise sur la virtualisation de fonctions réseau, c’est-à-dire un traitement optimisé des opérations d’entrée-sortie et de gestion des paquets à travers une interface directe vers la carte réseau (GPUDirect). cuBB est plutôt orienté vers la couche physique, donc du traitement de signal (ce pour quoi les GPU excellent depuis longtemps), avec notamment cuPHY pour l’implémentation de la couche physique de la 5G. Il existe déjà des cartes réseau compatibles avec la technologie GPUDirect, par exemple la Mellanox CX-5. Pour les GPU, toute la gamme NVIDIA est utilisable, depuis les Jetson Nano jusqu’aux serveurs EGX.
MATLAB est un environnement de développement pour le calcul numérique au sens large. Il intègre notamment des fonctionnalités de visualisation avancées, des possibilités de calcul numérique (suite au rachat de MuPAD), de modélisation (Simulink), mais aussi des boîtes à outils pour des domaines scientifiques (robotique, apprentissage profond, optimisation numérique, etc.). MATLAB est aussi composé d’un langage de programmation propriétaire (dérivé de Fortran et d’APL), qui permet la programmation impérative, orientée objet et orientée tableaux, mais aussi fonctionnelle.
La version 2019b, la deuxième version annuelle de MATLAB, vient de sortir. L’éditeur en temps réel de MATLAB (équivalent aux calepins de Mathematica ou Jupyter) combine code et résultats (y compris sous la forme de graphiques). La nouvelle itération dispose d’un explorateur de paramètres et d’une fenêtre de prétraitement des données : l’intérêt est que MATLAB peut générer automatiquement le code pour faire appel à ces fonctionnalités dans le calepin.
La boîte à outils Automated Driving s’enrichit d’une connexion avec Unreal Engine : on peut désormais simuler un environnement complexe dans Unreal Engine, avec une voiture contrôlée depuis MATLAB (notamment avec l’utilisation d’une série de capteurs : caméras, lidar et radar). Il est possible d’importer des scénarios de conduite depuis l’application dédiée.
La boîte à outils Navigation fait son apparition et offre des implémentations d’algorithmes utiles pour la navigation (pour une voiture autonome ou un robot). Notamment, elle offre une fonction pour déterminer la pose d’un véhicule à l’aide d’un capteur GPS et d’une centrale à inertie, mais aussi une implémentation de SLAM, pour créer une carte de l’environnement en l’explorant.
La boîte à outils Robotics est séparée en deux parties, pour créer la boîte à outils ROS, focalisée sur la communication avec des robots et des simulateurs utilisant les protocoles ROS et ROS 2. En pratique, cela signifie qu’il faudra acheter une licence supplémentaire pour les mêmes fonctionnalités…
La boîte à outils Deep Learning gère de nouvelles architectures de réseaux, notamment des GAN, ainsi que les réseaux avec des partages de poids (comme les techniques avec des réseaux siamois). Pour ce faire, la structure dlnetwork représente une architecture de réseau neuronal, puis facilite l’implémentation de procédures d’optimisation (calcul du gradient sur des minilots de donées à l’aide de dfleval et modelGradients).
Le domaine de l'”intelligence artificielle” (en pratique, juste des réseaux neuronaux profonds) nécessite d’énormes quantités de calculs, donc d’énergie : pour entraîner et optimiser les hyperparamètres d’un modèle (un total de 4789 tentatives, 239 942 heures de calcul), il faut entre cent et trois cent cinquante mille dollars (en louant de la puissance de calcul). En émissions de CO2 (méthodes de calcul dans l’article, section 2), on parle de 35 600 kg ; en comparaison, une voiture en émet, sur toute sa durée de vie, 57 000 kg.
L’entraînement de ces réseaux neuronaux a commencé sur des CPU, puis sur des cartes graphiques, avec une grande diminution des temps de calcul et de la consommation énergétique. Pour aller plus loin, une jeune société, Cerebras, propose de changer d’approche. Un CPU compte quelques milliards de transistors, des GPU jusqu’une vingtaine, le processeur de Cerebras monte à mille milliards de transistors, sur une puce bien plus grande (cinquante-six fois plus grande que le plus grand GPU actuem). Un seul tel processeur pourrait remplacer plusieurs centaines de GPU, notamment grâce à une grande réduction des communications entre processeurs.
Cette puce comporte une très grande quantité de mémoire : 18 Go de registres (SRAM) sur la puce ; une quantité aussi astronomique de cœurs de calcul : 400 000. En comparaison, la carte de calcul la plus superlative de NVIDIA (la T4) monte à 16 Go de mémoire (GDDR6, bien plus lente que de la SRAM) et 2560 cœurs. D’une certaine manière, cette puce est un interposeur sur silicium. À terme, la société envisage de vendre des serveurs complets construits autour d’une telle puce, plutôt que de les vendre à l’unité ou comme cartes d’extension ; aucun prix n’a encore été annoncé.
Ces puces sont fabriquées par TSMC, certains membres de la société en ont parlé comme des plus grandes puces jamais fabriquées. De manière générale, les puces sont fabriquées par photolithographie sur des galettes (circulaires) de silicium, d’un diamètre souvent de 300 mm : on ne peut placer qu’une seule puce de Cerebras sur une telle galette, par conception. D’habitude, on peut placer plusieurs centaines de puces sur une même galette ! Cette distinction a même fait que TSMC a dû adapter ses machines.
Philippe Notton est en charge du projet (il est administrateur délégué de l’EPI) et a annoncé que le processeur sera composé de plusieurs composants indépendants : des cœurs ARM, des cœurs RISC-V, de la mémoire HBM, au moins. Trois générations sont d’ores et déjà prévues : Rhea, qui devrait arriver en 2021 et devrait être utilisée dans des prototypes de superordinateurs d’un exaflops ; Cronos, dès 2022, pourrait arriver dans les premiers superordinateurs en production ; la troisième génération n’a pas encore de nom, mais devrait arriver dès 2024 et être utilisée dans la deuxième vague de superordinateurs. Si tout se passe bien, ces puces auront une déclinaison entreprise, à direction du marché des serveurs.
Toute la technologie intégrée dans ces processeurs ne seront pas forcément européennes. L’architecture ARM a été développée par la société britannique ARM, désormais rachetée par le conglomérat SoftBank (le côté européen étant déjà entaché par le Brexit). La mémoire HBM n’est pas fabriquée par des Européens non plus. L’architecture RISC-V a débuté dans une université américaine, Berkeley. Les différentes parties du processeur seront rassemblées par un interposeur, à la manière des pucettes. Pour le moment, il n’existe que deux technologies pour y arriver : Intel EMIB et TSMC CoWoS — aucune d’entre elles n’est européenne, d’ailleurs.
Les cœurs ARM serviront de contrôleurs principaux, avec des processeurs auxiliaires : les cœurs RISC-V (conçus par l’EPI), des processeurs vectoriels (Kalray MPPA — massively parallel processor array, conçus en France), des FPGA (conçus par Menta, encore une société française). Tous ces éléments seront inclus dans un interposeur, avec une architecture en grille : les contrôleurs (DDR, PCIe, HBM) seront connectés sur ce même réseau.
Plus précisément, les MPPA sont prévus pour le calcul de haute performance dans des à faible consommation (embarqué, réseau, stockage). Ils serviront probablement plus dans la déclinaison automobile des processeurs, mais pourraient se faire une place de choix dans des superordinateurs pour certaines opérations de réduction.
Le FPGA sera, bien évidemment, entièrement reconfigurable. A priori, il ne s’agira pas d’un modèle embarquant une série de composants extérieurs, au contraire de Xilinx Versal : la société Kalray se concentre sur la conception d’un FPGA que l’on peut embarquer dans n’importe quelle conception de puce.
Les cœurs RISC-V formeront l’accélérateur EPAC, avec jusque huit processeurs vectoriels par accélérateur (un accélérateur occupant une case dans la grille du processeur). Ils partageront le cache L2. Pour accélérer les opérations de calcul, les opérations de pochoir seront incluses (pour n’effectuer des calculs que sur une partie d’un registre vectoriel). Une unité orientée réseaux neuronaux sera aussi développée dans ce contexte, mais ne sera pas incluse dans les processeurs pour superordinateurs.
L’équilibre entre ARM et RISC-V est difficile à trouver : entre les frais de licence ARM et les risques liés à l’architecture RISC-V (pas encore mature). La situation continuera à évoluer dans les années à venir, avec différents nombres de cases ARM ou RISC-V dans les processeurs proposés.
L’objectif, à terme, est cependant de disposer d’un processeur entièrement européen, quitte à arriver plus tard sur le marché. Pour y arriver, il faudra développer fortement l’écosystème existant, notamment au niveau de la production — et obtenir des avantages en dehors des superordinateurs, avec une industrie des semi-conducteurs bien plus développée qu’actuellement.
Pour le moment, deux applications informatiques demandent une énorme puissance de calcul : le calcul scientifique (simulations industrielles et académiques) et l’entraînement de réseaux neuronaux profonds. Les deux domaines sont relativement séparés, bien qu’ils effectuent des opérations très similaires (de l’algèbre linéaire) : bon nombre de sociétés conçoivent des puces optimisées pour l’entraînement de réseaux neuronaux, mais difficilement utilisables en calcul scientifique. La différence majeure réside dans le fait que les réseaux neuronaux n’ont pas besoin d’une précision très grande pour stocker les nombres — contrairement au calcul scientifique, où quelques décimales manquantes peuvent donner des solutions totalement fausses… et on parle de simulations de centrales nucléaires, pas de reconnaissance de chats.
Sauf que… La communauté du calcul scientifique s’intéresse de plus en plus aux calculs en “précision mixte”, car les possibilités d’accélération au niveau matériel sont plus grandes que pour les opérations habituelles, en pleine précision. De fait, toutes les opérations ne requièrent pas une précision absolue pour les calculs : l’idée est d’alors utiliser des opérations en précision mixte quand cela ne nuit pas au résultat final.
En pratique, une équipe jointe de l’université du Tennessee et de celle de Manchester a adapté les tests de performance utilisés pour les superordinateurs afin d’exploiter la puissance des cœurs tensoriels fournis sur les dernières puces de NVIDIA. L’algorithme itératif de résolution de systèmes linéaires de Linpack a bénéficié des possibilités de calcul mixte de ces unités, avec une technique de raffinement itératif. Cette technique de calcul a été développée dans les années 1940 et est surtout utile dans le cas de matrices denses (dont beaucoup d’éléments sont non nuls). Le résultat est alors obtenu bien plus rapidement qu’en utilisant uniquement les unités de calcul sur soixante-quatre bits de ces puces graphiques. Les cœurs tensoriels offrent la possibilité de travailler avec des nombres sur seize bits à peine, avec des accumulateurs sur trente-deux bits. Numériquement, un superordinateur peut ainsi espérer tripler son score de performance ! C’était par exemple le cas de Summit : la résolution du même système linéaire (une matrice de dix millions de lignes et autant de colonnes) prend alors vingt-cinq minutes au lieu de septante-cinq.
Reste à voir comment ces techniques pourront s’appliquer de manière plus générale, à d’autres algorithmes de calcul numérique. On aura peut-être droit à une petite révolution dans le domaine, avec une très nette amélioration de performance sans dégradation de précision !
Thibaut Cuvelier 