Sortie de LLVM 3.8

Avec à peu près un mois de retard sur le planning, la nouvelle version de la suite de compilation LLVM est sortie, numérotée 3.8. Elle inclut notamment le compilateur C et C++ Clang. Quelques points sont mis en évidence par les développeurs :

  • OpenMP est maintenant activé par défaut dans Clang (la norme en version 3.1 était disponible en préversion dès Clang 3.7, le travail continue pour OpenMP 4.0 puis 4.5) ;
  • la compatibilité avec les autres compilateurs : une gestion des exceptions compatible avec les compilateurs Microsoft sous Windows, du TLS (une zone de mémoire privée pour chaque fil d’exécution pour des programmes parallèles à mémoire partagée) compatible avec GCC ;
  • la compilation de LLVM se fait maintenant de manière privilégiée avec CMake (plutôt que les autotools) ;
  • le tutoriel Kaleidoscope a été retravaillé pour faciliter l’utilisation de la plateforme LLVM par de nouveaux développeurs (notamment pour gérer d’autres langages en entrée) ;
  • LLVM ne garantit plus la compatibilité avec les versions les plus anciennes de Windows, c’est-à-dire antérieures à Windows 7.

Calcul de haute performance

Pour le calcul de haute performance, cette nouvelle version apporte bien des nouveautés intéressantes. Un certain nombre de fonctionnalités d’OpenCL 2.0 est implémenté, notamment au niveau de la gestion des espaces d’adressage ou encore des types atomiques (compatibles avec ceux définis par C11) et d’images (des tableaux bidimensionnels, comme image2d_depth_t ou image2d_array_depth_t).

Du côté d’OpenMP, la version 3.1 de la norme est maintenant entièrement supportée. À l’exécution, ce ne sera plus la bibliothèque GCC OpenMP qui sera utilisée, mais bien celle de Clang, développée par Intel (et développée à partir de celle utilisée pour leurs compilateurs propriétaires). Le développement continue pour OpenMP 4.0 et 4.5, avec notamment les clauses map, num_teams et thread_limit ou encore les dépendances entre tâches.

Pour CUDA, la technologie propriétaire de calcul sur processeurs graphiques de NVIDIA, les fonctionnalités arrivent petit à petit (elles sont toujours considérées comme expérimentales). Le code de Google n’est toujours pas intégré à Clang, mais il peut maintenant s’interfacer avec cette version sans modification spécifique.

Source : [llvm-announce] LLVM 3.8 Release, Clang 3.8 Release Notes

CNTK, la solution de Microsoft pour l’apprentissage profond, devient libre

Il y a peu, Google a mis à disposition des développeurs TensorFlow, sa solution d’apprentissage profond, une technique d’apprentissage automatique qui exploite principalement des réseaux neuronaux de très grande taille : l’idée est de laisser l’ordinateur trouver lui-même, dans sa phase d’apprentissage, des abstractions de haut niveau par rapport aux données disponibles. Par exemple, pour reconnaître des chiffres dans des images, ces techniques détermineront une manière d’analyser l’image, d’en récupérer les éléments intéressants, en plus de la manière de traiter ces caractéristiques et d’en inférer le chiffre qui correspond à l’image.

Microsoft vient tout juste d’annoncer sa solution concurrente, nommée CNTK (computational network toolkit), elle aussi disponible gratuitement sous une licence libre de type MIT sur GitHub. Cette annonce poursuit la série d’ouvertures de code annoncées par Microsoft dernièrement, comme ChakraCore, son moteur JavaScript.

Ces développements ont eu lieu dans le cadre de la recherche sur la reconnaissance vocale : les équipes de Microsoft estimaient que les solutions actuelles avaient tendance à les ralentir dans leurs avancées. Quelques chercheurs se sont lancés dans l’aventure d’écrire eux-mêmes un code de réseaux neuronaux très efficace, accéléré par GPU… et leurs efforts ont porté leurs fruits, puisque, selon leurs tests, CNTK est plus efficace que Theano, TensorFlow, Torch7 ou Caffe, les solutions les plus avancées dans le domaine du logiciel libre.

Microsoft n’est pas la seule société à beaucoup parier sur les GPU : NVIDIA également croit fort aux GPU pour accélérer l’apprentissage profond. Pour la sortie de la dernière version de CUDA, la solution de NVIDIA pour le calcul sur GPU, leur bibliothèque cuDNN proposait un gain d’un facteur deux pour l’apprentissage d’un réseau.

L’avantage des GPU dans le domaine est multiple. Tout d’abord, leur architecture s’adapte bien au type de calculs à effectuer. Ensuite, ils proposent une grande puissance de calcul pour un prix raisonnable : pour obtenir la même rapidité avec des processeurs traditionnels (CPU), il faudrait débourser des milliers d’euros, par rapport à une carte graphique à plusieurs centaines d’euros à ajouter dans une machine existante. Ainsi, les moyens à investir pour commencer à utiliser les techniques d’apprentissage profonds sont relativement limités. Cependant, la mise à l’échelle est plus difficile : l’apprentissage sur plusieurs GPU en parallèle est relativement difficile, toutes les bibliothèques ne le permettent pas. Pour réaliser de véritables progrès algorithmiques, il faut sortir le carnet de chèques, avec des grappes de machines, nettement moins abordables.

Source : Microsoft releases CNTK, its open source deep learning toolkit, on GitHub.

AMD prépare une nouvelle structure d’interconnexion

Pour les serveurs et plus particulièrement encore le calcul de haute performance (notamment sur superordinateur), les bus traditionnel pour connecter les différences parties d’un ordinateur (processeur principal — CPU —, accélérateurs — GPU, APU, FPGA…) deviennent limitants : avec de piètres débit et latence en comparaison des possibilités des éléments connectés, ils brident quelque peu le matériel utilisé — mais la situation ne s’améliorera pas avec les nouvelles générations. AMD, souhaitant se relancer dans ces marchés très juteux, est en train de développer sa propre solution, que l’on ne manquera pas de comparer à la solution concurrente NVLINK de NVIDIA (qui devrait débarquer cette année sur le marché).

Actuellement, des cartes graphiques comme les AMD Radeon R9 Fury ou NVIDIA Tesla K80 fournissent une belle capacité de calcul, mais elle n’est pas suffisante pour les besoins des utilisateurs les plus exigeants. AMD pourrait mieux répondre à ces besoins en alignant une série de ces cartes et en leur permettant de bien communiquer entre elles (sans devoir passer par le processeur central). Idéalement, cet assemblage devrait s’utiliser comme une seule et unique carte, beaucoup plus puissante, mais cela n’est actuellement pas vraiment possible, notamment à cause des limitations des technologies pour lier ces cartes (CrossFire chez AMD, SLI chez NVIDIA). Ces nouvelles structures d’interconnexion ne devraient pas se limiter aux cartes graphiques, mais devraient s’ouvrir à d’autres types d’accélérateurs, comme des FPGA.

La solution d’AMD, toujours en cours de développement, devrait offrir des débits de l’ordre de cent gigabits par seconde entre processeurs (contre une trentaine pour la prochaine version de PCI Express, attendue pour 2017), à comparer au double pour NVLINK. La différence principale est cependant que l’approche de NVIDIA ne fonctionne qu’entre processeurs NVIDIA et IBM POWER (deux superordinateurs utilisant cette technologie ont déjà été commandés), alors que AMD est plus ouvert, en mettant l’accent sur des normes ouvertes.

Source : AMD Talks Next Generation Coherent Interconnect Fabric Connecting Polaris GPUs, Zen CPUs and HPC APUs.

Quelles pistes pour les superordinateurs d’un exaflops ?

En 1964 a été construit le premier superordinateur, nommé Control Data 6600, avec une puissance de calcul d’un mégaflops, c’est-à-dire un million d’opérations en virgule flottante chaque seconde (comme additionner deux nombres à virgule). Il a été conçu par Seymour Cray, qui a lancé la société Cray, connue pour son activité dans les supercalculateurs.

Vingt et un ans plus tard, en 1985, la barre du gigaflops a été franchie par Cray-2. Actuellement, un processeur haut de gamme (comme un Intel i7 de dernière génération) fournit approximativement cent gigaflops.

Une dizaine d’années plus tard, en 1997, ASCI Red explose le téraflops, mille milliards d’opérations en virgule flottante par seconde ; dans cette série de records, c’est le premier à ne pas être associé au nom de Cray. Un processeur graphique moderne haut de gamme (comme la GeForce GTX Titan X) dépasse maintenant quelques téraflops.

Il y a presque dix ans, Roadrunner atteignant le pétaflops, en combinant une série de processeurs similaires à ceux utilisés dans les PlayStation 3. Aujourd’hui, le plus puissant est Tianhe-2, installé en Chine (alors que les précédents sont américains), avec une cinquantaine de pétaflops. La route semble encore longue jusqu’à l’exaflops, c’est-à-dire un milliard de milliards d’opérations en virgule flottante par seconde. À nouveau, les États-Unis ont lancé un projet pour atteindre cette puissance de calcul à l’horizon 2020 — plus particulièrement, le Département de l’Énergie, le même à investir massivement dans un compilateur Fortran moderne libre.

Ces nombres paraissent énormissimes : un milliard de milliards d’opérations par seconde. Outre les aspects purement informatiques, ce genre de projets a une grande importance pour la recherche scientifique : les laboratoires américains de l’Énergie étudient notamment l’arme nucléaire et la destruction en toute sécurité d’ogives ; en Europe, le Human Brain Project vise à simuler toute l’activité cérébrale d’un cerveau humain au niveau neuronal, ce qui nécessiterait une puissance de calcul de cet ordre de grandeur.

Comment y arriver ?

Le Département de l’Énergie estime que, actuellement, toutes les technologies nécessaires pour construire un tel superordinateur sont réunies. Cependant, il serait extrêmement difficile de l’alimenter : il faudrait un réacteur nucléaire complet pour y arriver ! Même si la construction de réacteurs fait partie de ses compétences, l’objectif de l’administration est de proposer une machine qui ne consomme « que » vingt mégawatts (un réacteur nucléaire produit généralement mille mégawatts). Erik DeBenedictis voit trois technologies pour réduire la consommation du facteur cinquante demandé : des transistors opérant à une tension d’un millivolt, la mémoire 3D et les processeurs spécialisés.

En théorie, un transistor peut fonctionner avec des tensions bien plus faibles qu’actuellement, en passant d’un volt à quelques millivolts à peine, ce qui augmenterait l’efficacité énergétique des processeurs d’un facteur dix à cent à court terme (jusqu’à dix mille à plus long terme !). La diminution de tension a jusqu’à présent suivi la loi de Moore, suivant la taille des transistors ; cependant, elle est bloquée depuis une décennie au niveau du volt… mais personne ne sait comment y arriver. Plusieurs technologies pourraient néanmoins passer cette barre :

Les mémoires empilées (aussi dites « en trois dimensions ») sont d’ores et déjà en cours de déploiement, sous des noms comme HBM ou HMC, dans les processeurs graphiques haut de gamme ou des accélérateurs spécifiquement prévus pour le calcul scientifique. Ils permettent une grande réduction de la consommation énergétique, d’autant plus enviable que l’objectif de vingt mégawatts réserve un tiers de la consommation à la mémoire. Une autre piste serait d’abandonner autant que possible la mémoire non volatile, pour passer par exemple à la mémoire résistive, comme la technologie Octane d’Intel.

Le troisième axe de recherche propose d’exploiter des architectures beaucoup plus spécifiques aux problèmes à résoudre. Elle est déjà exploitée, puisqu’une bonne partie des superordinateurs les plus puissants utilisent des processeurs graphiques. Cependant, Erik DeBenedictis propose de pousser l’idée plus loin encore : installer des processeurs extrêmement spécifiques aux tâches à réaliser, qui seraient activés seulement quand ils sont nécessaires. Pour effectuer d’autres types de calculs sur l’ordinateur, il faudrait alors installer d’autres processeurs spécialisés, ce qui n’est plus déraisonnable actuellement, au vu du prix des puces spécialisées.

Des compromis à réaliser

Ces trois pistes ont l’air intéressantes, mais n’ont pas du tout les mêmes propriétés quant au modèle de programmation actuel : si la physique derrière les processeurs change complètement, ils restent programmables de la même manière ; par contre, pour exploiter efficacement de nouveaux processeurs spécialisés, il faudrait changer complètement sa manière de pensée. La mémoire est dans une situation intermédiaire : empilée sur le processeur, les délais d’accès changent radicalement, l’ancien code n’est donc plus aussi efficace s’il tirait parti de ces spécificités, mais continuera à fonctionner ; au contraire, pour la mémoire résistive, il n’y aurait plus de distinction entre la mémoire utilisée pour effectuer les calculs et celle pour le stockage à long terme.

Sources : Three paths to exascale supercomputing (paru en ligne sous le titre Power problems threaten to strangle exascale computing), FLOPS.

Merci à Claude Leloup pour ses corrections.

En réponse à GameWorks, AMD annonce GPUOpen

Depuis quelques années, NVIDIA a lancé sa suite de bibliothèques logicielles baptisée GameWorks. Elles sont spécifiquement prévues pour le jeu vidéo et donnent la possibilité aux développeurs d’intégrer aisément des effets, comme la simulation de poils en tout genre avec HairWorks ou encore d’herbe avec Turf Effects. La famille compte aussi GameWorks VR, qui promet d’importants gains en performance pour les jeux exploitant la réalité virtuelle.

NVIDIA met en avant l’optimisation effectuée sur ces implémentations et la facilité d’intégration, ce qui décharge les studios d’une bonne partie du travail… sauf qu’il semblerait que l’optimisation peut se faire au détriment d’AMD. L’exemple de Witcher 3 a montré que HairWorks exploitait un point fort du matériel vendu par NVIDIA, la tesselation — ce qui nuisait fortement à la performance sur les cartes AMD.

Une stratégie : l’ouverture

Justement, AMD prépare sa réponse à GameWorks sous le nom de GPUOpen, en arrêtant de se focaliser sur l’aspect matériel du jeu vidéo. La différence principale par rapport à GameWorks est la licence du code : là où les bibliothèques GameWorks sont disponibles gratuitement après enregistrement, sous une licence propriétaire peu restrictive (les sources sont disponibles sur demande sous licence), AMD envisage de proposer ses bibliothèques GPUOpen comme logiciels libres, sous licence MIT, distribués sur GitHub, dès janvier. Rien n’indique cependant que le développement aura bien lieu sur GitHub et que les contributions seront facilement acceptées (y compris les optimisations pour le matériel autre que celui d’AMD).

Cet élément n’est pas le premier de la stratégie actuelle de AMD. Peu auparavant, ils avaient annoncé une couche de compatibilité avec CUDA, la technologie propriétaire de calcul sur processeur graphique de NVIDIA. AMD a aussi lancé une nouvelle version de leurs pilotes pour carte graphique, dénommée Radeon Software Crimson Edition, qui a apporté un tout nouveau panneau de configuration, bien plus pratique à l’usage que le précédent, ainsi qu’une performance améliorée pour les jeux (bien qu’invisible sous Linux). Globalement, AMD essaye de rattraper son retard par rapport à ses concurrents du côté PC — malgré son omniprésence sur le marché des consoles.

Du contenu pour les jeux…

Dans les bibliothèques disponibles, une bonne partie du contenu sera tout à fait nouveau. Il y aura bien sûr TressFX, sa solution de simulation de cheveux, poils et brins d’herbe, dans la version 3.0. Elle était déjà disponible gratuitement, sources comprises, sur le site d’AMD — un mécanisme moins facile d’accès que GitHub. Également, AMD devrait rendre disponibles en janvier les bibliothèques GeometryFX (opérations géométriques ou simulation physique, selon les sources), ShadowFX pour les ombres et AOFX pour l’occultation ambiante. AMD inclura ses exemples de code, tant pour DirectX 11 et 12 qu’OpenGL.

Les bibliothèques proposées ne devraient pas seulement s’étendre du côté des effets pour des jeux vidéo, avec notamment LiquidVR pour la réalité virtuelle, le moteur de rendu par lancer de rayons FireRender et la bibliothèque de lancer de rayons FireRays, RapidFire pour le déploiement dans le nuage. Pour faciliter le développement, AMD devrait aussi fournir CodeXL pour l’analyse statique de code (y compris pour DirectX 12) et Tootle pour le prétraitement des maillages des modèles 3D à afficher afin d’améliorer la performance au rendu (même si le développement de cet outil a officiellement cessé en 2010).

… mais pas seulement !

GPUOpen ne profitera pas seulement au secteur du jeu vidéo, mais aussi pour le calcul de haute performance, l’initiative Boltzmann étant incluse sous ce nom, avec un nouveau compilateur HCC, un pilote pour Linux spécifiquement optimisé pour le calcul sur GPU ou encore HIP pour la compatibilité avec CUDA.

Ils participent aussi au projet Caffe, actif dans le domaine de l’apprentissage profond (technique notamment utilisée avec succès dans la vision par ordinateur), pour lequel ils optimisent une version OpenCL (sans indiquer d’avantage en performance par rapport à cuDNN, l’option de NVIDIA).

Du libre aussi pour Linux

Le dernier point mis en avant par AMD pour ce projet GPUOpen est la mise en place effective de leur architecture de pilote libre pour leurs cartes graphiques. La performance des pilotes actuellement fournis par AMD n’est pas optimale pour tous les types d’utilisation, étant parfois largement dépassés par l’implémentation complètement libre Radeon — les deux étant souvent décrits comme largement en deçà des attentes, notamment pour les machines Steam.

La nouvelle architecture, déjà annoncée l’année dernière, s’articule autour d’une partie libre — AMDGPU —, directement incluse dans le noyau Linux. Cette partie n’aura aucune implémentation des piles graphiques telles que OpenGL ou Vulkan — totalement inutiles dans les applications de calcul pur.

Ensuite, les implémentations libre et propriétaire pourront diverger pour tout ce qui concerne OpenGL, l’accélération du décodage de vidéos, OpenCL et HSA. L’implémentation propriétaire d’OpenCL et de Vulkan devrait être distribuée en libre dans le futur, un mouvement qui n’est pas encore prévu pour OpenGL. Les fonctionnalités spécifiques aux cartes professionnelles FirePro seront, bien évidemment, uniquement propriétaires, même si rien n’empêche l’implémentation libre de les fournir.

Ces suppléments au pilote noyau fonctionneront entièrement en espace utilisateur, ce qui devrait améliorer la sécurité de l’implémentation et diminuer le nombre de changements de contexte utilisateur-noyau.

Sources : présentation d’AMD, Direkte Kontrolle der Radeon-Hardware für Spieleentwickler, AMD Further Embraces Open Source with GPUOpen, for Games and Compute, AMD embraces open source to take on Nvidia’s GameWorks.

Merci à Claude Leloup pour ses corrections.

Altera annonce le premier FPGA lié à de la mémoire superposée HBM2

Pour les processeurs graphiques, une limite fondamentale est depuis longtemps la mémoire, très lente par rapport aux débits que peut traiter un processeur : le bus est relativement rapide (de l’ordre de deux cents mégabits par seconde pour de la GDDR5), mais insuffisant pour tenir toutes les unités de calcul en activité (plus d’un térabit par seconde requis). L’avancée la plus récente (présente dans la série AMD Fiji et dans la prochaine génération côté NVIDIA) est le remplacement de cette mémoire par des composants embarqués sur la puce du GPU par le biais d’un interposeur (d’où l’appellation de « mémoire empilée »), notamment HBM (high bandwidth memory) — une technologie équivalente au HMC (hybrid memory cube) utilisé par Intel pour certains processeurs. Les gains promis en bande passante sont de l’ordre d’un facteur dix !

Cette technologie — HBM — est maintenant également disponible sur certains FPGA d’Altera, avec le même genre d’intégration. Par rapport aux processeurs traditionnels (CPU ou GPU), ils ont l’avantage d’être entièrement configurable : ils n’ont pas d’instructions fixes, puisque l’utilisateur peut assembler comme il le souhaite les portes logiques pour adapter le matériel à ses besoins. L’avantage n’est pas de traiter des tâches plus spécifiques (les processeurs traditionnels peuvent toutes les effectuer), mais bien plus efficacement (en temps ou en énergie).

Cette innovation sera utile dans les cas où la mémoire est une limite (pas tellement pour les gains en énergie, bien que la technologie permette de réduire par deux tiers l’énergie requise par bit transféré), comme dans l’apprentissage automatique ou le traitement de flux vidéo 8K : les quantités de données à gérer sont alors astronomiques, avec parfois des garanties de délai à maintenir — et empêche d’implémenter des fonctionnalités plus avancées, qui demandent plus de calculs.

Les premiers prototypes seront envoyés à des clients choisis en 2016 et seront disponibles plus largement en 2017. Avec le rachat d’Altera par Intel, il reste à voir si ces FPGA seront également intégrés dans certains processeurs Xeon Phi (les prochains seront pourvus de mémoire HMC), notamment pour contrer le partenariat entre IBM et Xilinx.

Source : communiqué de presse, Intel and Altera Develop World’s First HBM2, 2.5D Stacked, SiPs With Integrated Stratix 10 FPGA and SoC Solution.

[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.

[SC15] Collaboration entre IBM et Xilinx

La conférence ACM/IEEE Supercomputing 2015 (SC15) est un haut lieu américain dédié aux superordinateurs, l’occasion pour les fabricants de présenter leurs dernières avancées dans de domaine. Ce lundi, IBM et Xilinx ont annoncé un partenariat stratégique autour de leurs FPGA et de leur intégration dans des systèmes OpenPOWER, principalement en ce qui concerne le calcul scientifique. Là où un processeur traditionnel (qualifié, par les électroniciens, d’ASIC — application-specific integrated circuit) est prévu uniquement pour certaines opérations, qui correspondent à des circuits gravés en dur dans le silicium, les FPGA (field-programmable gate array) peuvent se reconfigurer à l’envi : conceptuellement, ils peuvent créer des instructions spécifiques pour le traitement demandé, ce qui leur permet d’atteindre une performance extrême — et une efficacité énergétique plus importante.

De manière générale, les accélérateurs sont de plus en plus utilisés dans les superordinateurs pour contrebalancer la faiblesse de la croissance de la performance des CPU traditionnels. Par exemple, une bonne proportion du Top 500 des machines les plus puissantes au monde utilise ces accélérateurs (principalement des GPU) pour atteindre les sommets. Les FPGA sont également très présents sur le marché de niche du calcul de haute performance, notamment grâce à leur flexibilité : un CPU ou un GPU a une architecture invariable et adaptée à des situations différentes, quand un FPGA peut s’adapter à toutes les situations, bien qu’avec des fréquences moindres. Par exemple, Altera indique que, avec leurs produits, l’apprentissage d’un réseau neuronal profond peut s’effectuer deux fois plus vite que sur un GPU.

Pour l’instant, en calcul de haute performance, les FPGA sont plutôt intégrés comme des cartes d’extension, auxquelles le processeur principal peut accéder par le bus PCI Express (comme la gamme Virtex de Xilinx ou une des cartes proposées par Altera). L’objectif est d’arriver à un plus haut niveau d’intégration, comme Intel avec le rachat en juin d’Altera, grand concurrent de Xilinx — toujours pour tendre vers des systèmes de plus en plus intégrés, y compris comme AMD et ses APU, mêlant CPU et GPU sur une même puce.

Le niveau d’intégration de la technologie de Xilinx était déjà bon dans la plateforme POWER, en exploitant l’interface CAPI, spécifique à POWER et prévue pour la connexion vers tous les accélérateurs. Cette annonce marque surtout que les FPGA sont de plus en plus utiles et qu’IBM souhaite un partenariat plus privilégié avec au moins un fabricant qu’une simple compatibilité. Xilinx dispose maintenant d’un siège au conseil d’administration du consortium OpenPOWER, probablement au détriment d’Altera, suite au rachat par Intel.

Source : IBM and Xilinx Announce Strategic Collaboration to Accelerate Data Center Applications, IBM & Xilinx @ SC15: Collaborating For Better POWER/FPGA System Integration.

Un nouveau compilateur Fortran libre pour LLVM

La NNSA, la partie du Département de l’Énergie américain s’occupant de la sécurité nucléaire (NNSA), utilise énormément de calcul scientifique dans ses trois laboratoires nationaux (Lawrence Livermore, Los Alamos, Sandia) pour étudier le nucléaire dans ses applications militaires (y compris leur destruction). Leurs codes de calcul tendent souvent à mélanger plusieurs langages de programmation, généralement Fortran (populaire uniquement dans le milieu scientifique) et C ou C++ (plus généraliste), ils ont donc besoin d’un même compilateur pour tous ces langages. LLVM et Clang font leur nid dans le domaine du calcul scientifique (par exemple, avec des investissements de Google), mais ils ne peuvent rien faire pour du code Fortran.

Collaboration avec NVIDIA

Le projet lancé en collaboration avec NVIDIA est de développer un nouvel analyseur de code pour Fortran pour l’intégrer dans la galaxie LLVM. Ce choix a été posé par opposition à GCC, l’autre grande suite de compilateurs libre, notamment pour des raisons de licence : LLVM est distribué sous une licence de type BSD, bien plus permissive qu’une GPL. De plus, l’architecture globale de LLVM est très moderne et facilite la recherche dans le domaine des compilateurs, plus particulièrement de l’optimisation (un autre point souvent reproché à GCC). De plus, ce n’est pas la première fois que NVIDIA travaille avec LLVM.

Bien sûr, ce développement ne partira pas de zéro : le partenariat avec NVIDIA a été scellé à cause du rachat de PGI, une société spécialisée dans les compilateurs Fortran, C et C++ à destination spécifiquement du marché du calcul scientifique depuis plus de vingt-cinq ans (ce qui implique que ces compilateurs sont compatibles avec OpenMP et OpenACC). Ils sont notamment à l’Å“uvre dans le compilateur CUDA Fortran (raison du rachat par NVIDIA). Malgré ces origines, le communiqué de presse tient à rassurer : ce projet s’étendra sur plusieurs années (la première version utilisable devrait être disponible dans un an, vers la fin 2016) et suivra à la lettre les directives du projet LLVM pour le code et l’interface de programmation. Pas un mot, par contre, sur la collaboration avec Flang, un embryon de compilateur Fortran pour LLVM.

Plateformes

La performance pourrait poser question : le compilateur Fortran de PGI n’est pas connu pour proposer le code le plus rapide qui soit (voir, par exemple, les comparatifs de Polyhedron). L’espoir est que, couplé aux passes d’optimisation de LLVM, ce compilateur libre soit comparable aux meilleurs actuellement. Il pourrait aussi profiter de toutes les plateformes pour lesquelles LLVM peut générer du code binaire, principalement du x86, mais aussi MIPS ou les GPU.

Notamment, IBM parle déjà en bien de ce projet, par rapport à leur architecture POWER et le consortium OpenPOWER : ce compilateur pourra être utilisé sur leurs machines. D’ailleurs, IBM et NVIDIA sont à la manÅ“uvre pour la réalisation du superordinateur Sierra, qui devrait être installé dans le laboratoire de Lawrence Livermore, avec une puissance de cent pétaflops (juste derrière l’autre projet américain, Summit, prévu pour le laboratoire de l’Oak Ridge avec une puissance de cent cinquante pétaflops). Une grosse partie de la puissance devrait provenir des GPU. Les États-Unis espèrent, avec ces deux projets, de se remettre au plus haut niveau en termes de puissance de calcul : le plus gros supercalculateur, actuellement, est Tianhe-2, en Chine, avec une puissance de cinquante-cinq pétaflops.

Source : NNSA, national labs team with Nvidia to develop open-source Fortran compiler technology.

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).