NVIDIA détaille la version PCIe du Tesla V100

Quelques mois après la première annonce de ses processeurs graphiques pour le calcul intensif Tesla V100, NVIDIA dévoile les derniers détails sur la version PCIe de ces cartes. L’annonce précédente portait uniquement sur les modules SXM2, un format propriétaire nécessaire notamment pour le bus NVLink. Les grandes lignes de Volta sont déjà connues : ces puces de 815 mm² sont fabriquées avec un procédé spécifique de TSCM, le 12FFN, une variante du 12 nm ; l’architecture des cœurs fait place à des unités spécifiques aux traitements tensoriels, les caches L1 sont unifiés au sein d’un multiprocesseur de flux.

La version PCIe de ces cartes, certes plus standard, est quelque peu limitée par rapport au format SXM2 : la puissance délivrable est moindre (250 W au lieu de 300 W), ce qui limite de facto la fréquence des processeurs graphiques (qui passe de 1455 à 1370 MHz, soit une perte d’approximativement six pour cent). La puissance de calcul est donc aussi en baisse : au plus vingt-huit téraflops en demi-précision (au lieu de trente), par exemple. Le processeur en lui-même est identique, avec le même nombre de cœurs CUDA par exemple (5376). Cependant, la diminution de puissance de calcul n’est pas directement proportionnelle à la diminution d’énergie consommée : l’efficacité énergétique augmente donc (de cent gigaflops par watt à cent douze).

Contrairement à la génération Pascal (P100), ces processeurs spécifiquement prévus pour le calcul intensif ne seront pas déclinés en une gamme : le P100 existait en versions seize et douze gigaoctets de mémoire, le V100 n’existera qu’en version seize gigaoctets. Cela est probablement dû au fait que NVIDIA maîtrise mieux les processus de fabrication de puces avec interposeur (requis pour une mémoire de type HBM2) — ce qui diminue le taux de puces partiellement mal formées — et que la production de mémoire HBM2 a augmenté en volume.

On attend les premières cartes PCIe pour la fin de l’année, notamment intégrées dans des systèmes de HP Entreprise.

Source : NVIDIA Formally Announces PCIe Tesla V100: Available Later This Year.

Advertisements

Une nouvelle manière d’utiliser du code CUDA sur d’autres architectures : le projet Coriander

NVIDIA CUDA est et reste la technologie de choix pour l’utilisation de processeurs graphiques pour des calculs. Pour ainsi dire, toutes les bibliothèques d’apprentissage profond utilisent CUDA pour accélérer leurs calculs (pour la plupart, exclusivement) : TensorFlow, Caffe, Torch, Theano, etc. — même si quelques rares bibliothèques s’opposent à cette hégémonie, comme DeepCL. Cependant, cela pose un gros problème à l’écosystème : CUDA est limité aux processeurs fournis par NVIDIA, ce qui limite la concurrence.

C’est notamment pour cela qu’AMD a lancé le projet de transpilateur HIP, qui vise à transformer du code source CUDA en OpenCL. L’outil est vraiment prévu pour que le code source CUDA ne soit plus utilisé, qu’OpenCL le remplace sur toutes les plateformes — malgré les possibilités d’optimisation possibles uniquement avec CUDA pour les processeurs NVIDIA. Un défaut est que toutes les possibilités du langage CUDA ne sont pas gérées. Certains projets, comme Caffe ou Torch, ont lancé une opération de conversion manuelle, qui a le même genre de défauts : le développement se produit principalement en CUDA, pas en OpenCL.

Pour améliorer la situation, certains développeurs se sont lancés dans le projet Coriander (anciennement connu sous le nom de CUDA-on-CL) : ils agissent au moment de la compilation, pas sur les sources. Ainsi, un projet peut être développé entièrement avec CUDA, mais être portable sur toutes les architectures de processeurs graphiques (et d’autres plateformes compatibles OpenCL).

Le principe est proche de HIP : le code CUDA est compilé normalement avec Clang ; ensuite, Coriander traduit le code intermédiaire LLVM en code OpenCL 1.2, qui peut alors être recompilé pour n’importe quelle cible. La partie restante est alors l’API CUDA, qui permet de gérer finement l’exécution sur les processeurs, mais ce travail est actuellement moins abouti. La force de CUDA réside non seulement dans le langage de programmation des GPU, mais aussi dans les bibliothèques de fonctions courantes déjà implémentées et optimisées : pour ce faire, des parties considérables de cuBLAS et cuDNN ont déjà été portées.

À l’exécution, le code produit est moins performant que s’il était directement exécuté sur un GPU NVIDIA. Cependant, pour des tâches d’apprentissage profond, selon le type d’opérations à effectuer, les résultats peuvent être très proches de ceux de CUDA (opérations unitaires, tangente hyperbolique) ; d’autres sont clairement en-dessous (réductions). Cela est en bonne partie dû aux optimisations effectuées par les compilateurs de NVIDIA, mais aussi au fait que le projet Coriander génère du code OpenCL pas forcément traditionnel (afin de coller au mieux à la sémantique de CUDA et éviter des problèmes de correction).

Voir le code source de Coriander.

Source : présentation à IWOCL.

Annonce de CUDA 9

Parallèlement à ses derniers GPU (de génération Volta), NVIDIA annonce une nouvelle version de son API CUDA. Cette neuvième itération se concentre sur les nouvelles fonctionnalités des GPU annoncés, mais propose également de nouveaux algorithmes dans cuSolver et nvGraph, ainsi qu’un compilateur amélioré — plus rapide, compatible avec le code C++14 pour l’hôte — et une intégration pour les environnements de programmation les plus récents — Visual Studio 2017, Clang 3.9, PGI 17.1 et GCC 6.

Groupes coopératifs

Les algorithmes parallèles imposent souvent aux fils d’exécution de travailler de manière collective (et non parfaitement en parallèle et sans synchronisation), ce que le développeur peut faire en groupant certains et en synchronisant ces groupes. CUDA 9 apporte justement cette notion de groupes coopératifs.

De manière historique, le degré le plus fin de découpage des fils d’exécution est le bloc, qui correspond à une limite physique des premiers GPU entièrement programmables. La synchronisation ne pouvait ainsi se faire qu’entre ces blocs. Cette manière de programmer est difficile à bien assimiler et limite la performance. De plus, les interactions avec les bibliothèques extérieures sont plus compliquées.

Au contraire, un groupe coopératif est une subdivision plus fine du travail à effectuer, qui peut correspondre à un morceau de bloc ou à plusieurs blocs… voire plusieurs GPU. Les opérations collectives peuvent alors s’effectuer par rapport à ces groupe. Ainsi, le nombre de fils d’exécution par bloc peut varier pour s’adapter au matériel (et donc en extraire un maximum de performance), tandis que la synchronisation n’en pâtit pas.

Cette fonctionnalité est disponible sur toutes les générations de processeurs graphiques, mais pas tous les détails. Ainsi, la synchronisation entre GPU n’est possible qu’avec les processeurs Pascal et Volta, en-dessous d’une trame d’exécution uniquement avec Volta (grâce à un ordonnancement des fils d’exécution entièrement repensé).

Outils pour développeurs

Le profileur visuel a reçu deux améliorations majeures pour faciliter l’analyse de la performance des applications utilisant la mémoire unifiée. D’un côté, il montre maintenant les lignes de code où se produit chaque défaut de page du côté CPU (et donc où l’exécution du code doit être interrompue le temps de charger la zone de mémoire demandée).

De l’autre, la ligne du temps du profileur affiche trois types d’événements liés à l’utilisation de la mémoire unifiée :

  • les goulots d’étranglement (page throttling) qui se produisent quand un processeur est bloqué sur une page de mémoire le temps pour laisser un autre y accéder sans interruption ;
  • les écroulements (thrashing) qui indiquent qu’au moins deux processeurs accèdent à une même région en mémoire virtuelle à tour de rôle, ce qui fait que les pages concernées sont déplacées sans cesse d’un processeur à l’autre ;
  • une correspondance éloignée (remote map) pointe une région en mémoire virtuelle qui a été assignée à un autre processeur, notamment pour éviter un écroulement ou pour combler un manque de mémoire sur le processeur courant.

Cœurs tensoriels

Volta est la première architecture GPU de NVIDIA à fournir tant des cœurs de calcul génériques (CUDA) que spécifiques (tensoriels). Ces derniers sont prévus spécifiquement pour une opération : un cœur tensoriel peut mémoriser quatre matrices de seize éléments et effectuer l’opération D = A × B + C.

Chacun de ces cœurs effectue soixante-quatre opérations de multiplication-addition par coup d’horloge. Rassemblés dans une trame d’exécution, ils peuvent effectuer cette opération de multiplication et d’addition entre seize matrices carrées de seize éléments de côté. En continuant d’assembler ainsi les groupes de cœurs, on peut traiter des matrices de n’importe quelle taille, extrêmement rapidement. La principale limitation concerne la précision : les deux matrices à multiplier sont forcément FP16, tandis que les deux matrices d’accumulation peuvent être FP16 ou FP32.

Source et détails : CUDA 9 Features Revealed: Volta, Cooperative Groups and More.

Intel concurrence NVIDIA avec son nouveau Xeon Phi Knights Landing

Annoncée il y a de cela un an, la nouvelle mouture des processeurs Intel Xeon Phi, nom de code Knights Landing, était annoncée : ces processeurs sont maintenant livrés aux fournisseurs de matériel HPC. Avec ces nouvelles puces, Intel vise le même segment que NVIDIA avec ses cartes graphiques (GPU) de génération Pascal : l’apprentissage profond, le calcul scientifique de haute performance (HPC).

Actuellement, quatre modèles sont disponibles, avec un nombre de cœurs variable (de soixante-quatre à septante-deux) et des fréquences aussi variables (entre 1,3 et 1,5 GHz), des caractéristiques proches des GPU actuels comme NVIDIA Pascal. Tous sont livrés avec seize gigaoctets de mémoire vive (MCDRAM), empilée et très proche du processeur, pour une bande passante de presque cinq cents gigaoctets par seconde. Ces différentes puces représentent des compromis différents : la plus puissante (7290, 3,46 Tflops) est la plus chère (6294 $), avec un produit bien plus abordable au niveau du téraflops par euro (7210 à 2438 $ pour 2,66 Tflops) ; l’une optimise le ratio performance par watt (7250, 3,05 Tflops pour 215 W, là où le 7290 fournit 3,46 Tflops pour 245 W) et la dernière la mémoire disponible par cœur (7230, soixante-quatre cœurs, comme le 7210, mais la mémoire a une fréquence plus élevée).

Au niveau des chiffres bruts, ces processeurs ne dépassent pas l’offre de NVIDIA : “à peine” trois téraflops et demi pour le plus haut de gamme, quand les GPU NVIDIA Pascal atteignent cinq téraflops (et une bande passante de cinquante pour cent plus élevée, à sept cent vingt gigaoctets par seconde). Par contre, selon les applications, à cause de la différence d’architecture fondamentale, les résultats varient énormément (les Xeon Phi sont organisés comme des processeurs traditionnels : chaque cœur peut exécuter une instruction propre, contrairement aux GPU, où la même instruction est exécutée sur un grand nombre de cœurs). Ainsi, pour de la simulation de dynamique moléculaire, pour le test de performance LAMPPS, un Xeon Phi de milieu de gamme (7250) a fonctionné cinq fois plus vite en consommant huit fois moins de mémoire qu’un GPU NVIDIA K80 (la génération précédant les Pascal). Pour de la visualisation par lancer de rayon, Intel indique être cinq fois plus rapide ; le facteur descend à trois pour de la simulation de risque financier. Ces comparaisons ne sont pas entièrement équitables, à cause de la différence d’âge entre les processeurs, mais donnent la tendance qu’Intel veut montrer. Ces résultats devront être confirmés par des indépendants pour être fiables.

Parmi les tests de performance, Intel s’est aussi orienté vers l’apprentissage profond, branche dans laquelle NVIDIA s’impose actuellement. Ce domaine est actuellement à la pointe de la recherche, avec des résultats de plus en plus intéressants : c’est grâce à des techniques de ce genre que Google a pu battre le joueur le plus fort au monde au jeu de go. Sur un même jeu de test, un Xeon Phi 7250 a obtenu sa réponse en cinquante fois moins de temps qu’un seul processeur traditionnel ; avec quatre tels Xeon Phi, les temps de calcul ont été réduits d’un facteur deux par rapport à quatre GPU NVIDIA K80.

Intel précise également qu’il est plus facile de programmer ses processeurs Xeon Phi : ils embarquent beaucoup plus de cœurs, mais c’est la seule différence avec les processeurs habituels de nos PC, alors qu’il faut réécrire complètement son code (ou utiliser des API adaptées) pour les GPU, avec une phase d’optimisation du code qui nécessite des compétences plus spécifiques. La nouvelle génération de Xeon Phi apporte cependant une distinction plus importante : ces processeurs Intel pourront être utilisés comme processeurs principaux (pas seulement comme cartes d’extension), ce qui évite les opérations de transfert de données, très limitantes pour la performance des applications actuelles. Il reste cependant à déterminer si ces processeurs seront suffisamment rapides pour effectuer toutes les opérations des applications qui leur sont soumises (ils fonctionnent à une fréquence réduite par rapport aux processeurs habituels : ils excellent dans le traitement parallèle, mais pas en série, qui constitue parfois une part importante du code à exécuter).

Ni ces nouveaux Xeon Phi ni les GPU NVIDIA Pascal ne sont actuellement utilisés à grande échelle pour du calcul scientifique. Cependant, ces premiers résultats montrent que les deux jouent dans la même cour. Si les mesures d’Intel se généralisent, ils deviendront un concurrent plus que très sérieux de NVIDIA, notamment dans le marché en expansion de l’apprentissage profond ; s’ils ont en plus l’avantage du prix, la dominance de NVIDIA sera vite mise à mal.

Sources : Intel Takes on NVIDIA with Knights Landing Launch, Intel’s Knights Landing: Fresh x86 Xeon Phi lineup for HPC and AI, Intel Xeon Phi Knights Landing Now Shipping; Omni Path Update, Too.

Merci à Claude Leloup pour sa relecture orthographique.

NVIDIA annonce son architecture Pascal et CUDA 8

NVIDIA en parle depuis un certain temps et dégaine, peu après AMD, sa nouvelle générations de processeurs graphiques, dénommée Pascal, un nom qui fait référence à Blaise Pascal, mathématicien et physicien français du XVIIe siècle. Les chiffres bruts donnent déjà le tournis : un tel GPU est composé de dix-huit milliards de transistors (huit milliards pour la génération précédente, Maxwell).

Sur la technique, ce GPU (nommé GP100) est le premier gravé en 16 nm, avec la technologie FinFET+ de TSMC, les précédents l’étaient en 28 nm. Pour un processus aussi récent, la puce est énorme : 610 mm², à comparer au 600 mm² de Maxwell sur un processus bien maîtrisé. Cette surface est utilisée pour les 3840 cœurs de calcul (3072 pour Maxwell), ayant accès à un total de 14 Mo de mémoire cache (6 Mo pour Maxwell). Les cœurs ont aussi augmenté en fréquence : 1,5 GHz au lieu de 1,1 pour Maxwell. Au niveau de la mémoire principale, la technologie HBM2 est utilisée au lieu de la mémoire traditionnelle GDDR5. Une puce Pascal dispose de seize gigaoctets de mémoire (contre douze, il n’y a pas si longtemps, chez Maxwell, maintenant vingt-quatre).

NVIDIA peut donc en profiter pour intégrer bon nombre de nouvelles fonctionnalités, tournées vers le segment HPC, comme sa connectique NVLink. L’une des fonctionnalités très utiles pour monter en performance concerne les nombres à virgule flottante : contrairement à Maxwell, les unités de calcul de Pascal traitent nativement des nombres sur soixante-quatre bits et seize bits ; ainsi, une telle puce peut monter jusque vingt et un mille milliards d’opérations par seconde (21 TFlops) en seize bits, cinq mille milliards en soixante-quatre bits (avec un facteur d’à peu près quatre entre les deux : les unités sur soixante-quatre bits sont grosso modo composées de quatre unités sur seize bits).

Toujours dans le HPC, la mémoire unifiée, entre la mémoire principale de l’ordinateur et celle du processeur graphique, a aussi vu quelques améliorations. Elles se comptent au nombre de deux. Tout d’abord, l’espace d’adressage a été considérablement élargi, ce qui permet d’adresser toute la mémoire centrale et celle du GPU (et non seulement un espace équivalent à la mémoire du GPU). Ensuite, les GPU Pascal gèrent les défauts de page : si un noyau de calcul tente d’accéder à une page mémoire qui n’est pas encore chargée sur le GPU, elle le sera à ce moment-là, elle ne doit plus être copiée dès le lancement des calculs sur le GPU.

L’apprentissage profond, le cheval de bataille de NVIDIA

Toutes ces avancées sont jusque maintenant principalement prévues pour le marché du HPC, plus particulièrement de l’apprentissage de réseaux neuronaux profonds, à l’origine de miracles récents dans le domaine de l’intelligence artificielle.

NVIDIA avance un facteur d’accélération de douze dans un cas d’apprentissage d’un réseau neuronal avec sa nouvelle architecture par rapport à ses meilleurs résultats l’année dernière. Ce facteur est énorme en seulement une année, mais il faut remarquer que la comparaison proposée n’est pas toujours équitable : les nouveaux tests utilisent deux fois plus de GPU que l’année dernière, de nouvelles fonctionnalités ont fait leur apparition sur les GPU spécifiquement pour accélérer ce genre de calculs (les nombres à virgule flottante sur seize bits). Il n’empêche, le résultat reste impressionnant.

Ces avancées réunissent cinq « miracles », selon la terminologie de Jen-Hsun Huang :

  • la nouvelle architecture Pascal ;
  • la technologie de gravure de puces de TSMC ;
  • la nouvelle génération de puces mémoire empilées (HBM2) ;
  • la technologie d’interconnexion entre GPU NVLink ;
  • des améliorations algorithmiques pour tirer parti des progrès précédents.

NVIDIA DGX-1, un supercalculateur dans une boîte

Les tests de performance ont été effectués sur une machine assemblée par NVIDIA, dénommée DGX-1, un monstre de puissance. Elle couple deux processeurs Intel Xeon E5-2698 v3 et huit processeurs NVIDIA Pascal avec 512 Go de mémoire vive et 1,92 To de stockage en SSD. Globalement, la machine peut fournir 170 TFlops pour la modique somme de 129 000 $. NVIDIA la résume comme deux cent cinquante serveurs rassemblés dans un boîtier. Elle est d’ores et déjà en vente, mais les livraisons devraient débuter en juin. Des bibliothèques existantes ont été adaptées pour cette machine pour en tirer le meilleur parti, comme TensorFlow de Google.

CUDA 8 et autres avancées logicielles

Pascal vient avec des améliorations matérielles accessibles par CUDA 8, la nouvelle version de l’API de calcul sur GPU de NVIDIA. Par exemple, les opérations atomiques en mémoire, utiles pour les opérations en parallèle sur une même case mémoire sans risque de corruption, gèrent plus d’opérations sur les entiers (en parallèle avec une implémentation matérielle plus complète). Les développeurs peuvent exploiter une structure d’interconnexion NVLink explicitement depuis CUDA.

Le profilage d’applications est encore amélioré, notamment au niveau de la répartition de la charge entre le CPU et le GPU, pour déterminer les parties où l’optimisation serait la plus bénéfique globalement. Pour ce faire, le profileur visuel montre maintenant les dépendances entre les noyaux de calcul du GPU et les appels à l’API CUDA, afin de faciliter la recherche d’un chemin critique d’exécution.

De nouvelles bibliothèques font également leur apparition au sein de l’écosystème, comme nvGRAPH pour l’analyse de graphes : la planification du chemin d’un robot dans un graphe énorme (comme une voiture dans le réseau routier), l’analyse de grands jeux de données (réseaux sociaux, génomique, etc.). NVIDIA IndeX, une bibliothèque de visualisation de très grands jeux de données (répartis sur plusieurs GPU), est maintenant disponible comme extension à ParaView. cuDNN arrive en version 5, avec d’importantes améliorations de performance.

Sources : Pascal Architecture (images d’illustration), Nvidia Pascal Architecture & GP100 Specs Detailed – Faster CUDA Cores, Higher Thread Throughput, Smarter Scheduler & More, NVIDIA DGX-1 Pascal Based Supercomputer Announced – Features 8 Tesla P100 GPUs With 170 TFLOPs Compute, NVIDIA GTC 2016 Keynote Live Blog (transparents NVIDIA), Inside Pascal: NVIDIA’s Newest Computing Platform, CUDA 8 Features Revealed.

[SC15] AMD lance l’initiative Boltzmann

AMD s’est récemment lancé, comme Microsoft, dans une série d’actions d’ouverture de leur code source sous des licences libres, notamment au niveau de leurs pilotes pour Linux (AMDGPU). À un tout autre niveau, pour le calcul sur GPU, ils espèrent que leur architecture hétérogène (dite HSA) sera compatible avec les instructions de délégation de calcul d’OpenMP dans GCC 6 (qui devrait sortir début 2016), pour se mettre au même niveau qu’Intel (leur accélérateur Xeon Phi est déjà accessible par ce biais depuis GCC 5, c’est-à-dire début 2015). De même, ils explorent le côté LLVM des compilateurs libres, avec l’ouverture prévue du code de HCC, leur compilateur hétérogène pour leur plateforme HSA.

L’initiative Boltzmann prend le nom d’un physicien autrichien (ce qui n’est pas sans rappeler les noms de code des GPU NVIDIA), à l’origine de l’approche statistique en physique (ses travaux sont fondamentaux dans certaines utilisations actuelles des GPU). Cette initiative correspond à une revalorisation des GPU à destination des serveurs dans le marché du calcul de haute performance, avec notamment un pilote Linux prévu exclusivement pour le calcul sur ces GPU (sans aucune implémentation d’OpenGL). Leur compilateur HCC permettra d’y exécuter du code C ou C++ en utilisant OpenMP, un mécanisme de parallélisation assez général (pas initialement prévu pour les GPU), c’est-à-dire avec un seul et même langage et un seul compilateur pour une série de processeurs (de manière similaire au C++ AMP, proposé par Microsoft).

Une partie de cette initiative Boltzmann est prévue pour le portage des applications CUDA vers un “modèle de programmation C++ commun” aux différents types de processeurs disponibles, un modèle connu sous le doux nom de HIP (heterogeneous compute interface for portability). Il s’agit notamment d’effectuer une transpilation partielle du code CUDA, qui devrait être automatique pour nonante pour cent des cas courant — les dix pour cent restants devant être traduits à la main, ce décompte ne tenant pas compte de l’utilisation d’assembleur (PTX) ou de l’appel direct au pilote ; ce code transpilé sera toujours compilable pour les GPU NVIDIA. Au contraire, des applications CUDA compilées ne pourront pas directement être lancées sur un GPU AMD, ce qui nécessiterait l’implémentation complète dans le pilote d’une pile CUDA (et, accessoirement, une licence de la part de NVIDIA pour ce faire, déjà proposée dans le passé). Ce mouvement est absolument requis pour qu’AMD se relance dans la course du calcul scientifique de haute performance avec ses solutions GPGPU (et pas simplement des APU), au vu de la quantité de code CUDA existant.

Globalement, cette initiative Boltzmann matérialise un véritable retour en grande pompe dans le domaine du HPC, une niche très lucrative : le matériel existe déjà, mais l’environnement logiciel était encore défaillant pour reprendre des parts de marché, à Intel et NVIDIA. Les premiers résultats devraient arriver au premier trimestre 2016, avec des préversions. Restera à voir l’impact sur la performance.

Sources : AMD Launches ‘Boltzmann Initiative’ to Dramatically Reduce Barriers to GPU Computing on AMD FirePro™ Graphics, AMD @ SC15: Boltzmann Initiative Announced – C++ and CUDA Compilers for AMD GPUs (images), AMD Plans To Contribute Heterogeneous Compute Compiler, AMD Working On CUDA Source Translation Support To Execute On FirePro GPUs.

CUDA et LLVM, des nouvelles

Le compilateur officiel de NVIDIA pour ses extensions GPGPU aux langages C et C++, nvcc, n’est plus la seule option pour compiler ce code CUDA depuis la version 4.1. Depuis ces quelques années, cette contribution au compilateur libre LLVM fait son bout de chemin. L’idée est de générer du code PTX, c’est-à-dire l’assembleur utilisé sur les GPU NVIDIA, traduit par les pilotes officiels en instructions pour chaque GPU.

La semaine dernière, deux nouveautés sont arrivées dans les dépôts de LLVM et Clang au sujet de CUDA. La première est un guide rapide pour compiler le compilateur et commencer à l’utiliser, surtout à destination de chercheurs et développeurs de LLVM, notamment pour les aider à développer des passes d’optimisation spécifiques aux GPU. Pour ce faire, une série de modifications au niveau des sources de LLVM est nécessaire (l’implémentation s’oriente comme nvcc, avec du code pour l’hôte et le GPU mélangé dans un même fichier).

Ce document explicite notamment les optimisations déjà réalisées par LLVM et les modifications CUDA pour améliorer la performance sur les GPU. Notamment :

  • la réduction des redondances dans le calcul d’expressions mathématiques : si x=b*s a déjà été exécuté, l’affectation y=(b+1)*s sera réécrite comme y=x+s, ce qui évite de calculer le facteur b+1 en sus de la multiplication ;
  • l’inférence de l’espace mémoire à utiliser pour une variable (à choisir entre mémoires globale, constante, partagée et locale) ;
  • le déroulement des boucles et l’extension en ligne des appels de fonction plus agressifs que sur du code à destination de CPU, puisque tout transfert de l’exécution sur un GPU est bien plus coûteux que sur un CPU (tout saut, toute condition nuit fortement à la performance) ;
  • l’analyse du recouvrement entre pointeurs, dans le cadre d’une passe généralisée à tout LLVM (bien que cette partie spécifique aux GPU n’est pas encore intégrée) ;
  • l’évitement de divisions lentes sur soixante-quatre bits, par manque de circuits spécifiques pour cette opération sur les GPU NVIDIA (elles sont remplacées, autant que possible, par des opérations sur trente-deux bits).

Une bonne partie de ces optimisations a eu des contributions de la part de Google, qui pourraient sembler quelque peu inattendues. Leur objectif est de développer une plateforme à la pointe de la technologie pour la recherche sur la compilation pour GPU et le calcul scientifique de haute performance en général. Leurs premiers résultats, présentés par Jingyue Wu, indiquent que leurs avancées sur LLVM font aussi bien que le compilateur de NVIDIA, nvcc, sur certains tests… et vont parfois jusque cinquante pour cent plus vite que le code produit par nvcc ! Ceci s’accompagne d’un gain de huit pour cent en moyenne sur le temps de compilation (sans véritable intégration à Clang, puisque la compilation s’effectue en plusieurs phases bien séparées — GPU et CPU —, ce qui fait perdre pas mal de temps).