Abstractions Performantes Pour Cartes Graphiques

Transcription

1 UNIVERSITÉ PIERRE ET MARIE CURIE ÉCOLE DOCTORALE INFORMATIQUE, TÉLÉCOMMUNICATIONS ET ÉLECTRONIQUE Abstractions Performantes Pour Cartes. Graphiques MATHIAS BOURGOIN sous la direction d Emmanuel Chailloux et de Jean-Luc Lamotte THÈSE pour obtenir le titre de Docteur en Sciences mention Informatique Emmanuel Chailloux Jean-Luc Lamotte Marco Danelutto Jocelyn Sérot Carlos Agon Joël Falcou Gaétan Hains Stéphane Vialle Directeurs Université Pierre et Marie Curie Université Pierre et Marie Curie Rapporteurs Università di Pisa Université Blaise Pascal Examinateurs Institut de Recherche et Coordination AcoustiqueMusique Université Pierre et Marie Curie Université Paris-Sud Université Paris-Est Créteil Val de Marne École Supérieure d Électricité

2 Document mis en page avec X LATEX et la police E

3 «With great power, comes great responsability.» P. Parker alias Spider-Man

4 Remerciements Je tiens tout d abord à remercier mes deux directeurs de thèse, Emmanuel et Jean-Luc, qui au cours de ma thèse ont su, parfois malgré la distance, m orienter et me guider dans mes recherches et réflexions sans m ôter l autonomie et la liberté nécessaires à mon travail de recherche. Je suis particulièrement heureux d avoir réalisé cette thèse avec eux deux, sur un sujet qui me correspondait bien et qui associait parfaitement deux aspects de l informatique souvent considérés (à tort) comme opposés. Deux aspects que j ai découverts lors de mes années de licence, mais surtout lors de mes années de master. Je tiens d ailleurs à remercier toute l équipe enseignante qui m a mené jusqu ici. Je remercie très chaleureusement Marco et Jocelyn pour avoir accepté de rapporter ma thèse et pour leurs remarques bienveillantes qui m ont permis d améliorer mon manuscrit. Je remercie évidemment aussi Carlos, Joël, Gaétan et Stéphane d avoir accepté d être membres du jury de ma thèse. J en profite d ailleurs pour remercier l équipe de l école doctorale et en particulier Christian Queinnec, son directeur, qui ont toujours été très efficaces et réactifs pour répondre à mes questions au cours de la thèse et particulièrement sur la fin. Je pense bien sûr aussi à toute l équipe de la licence et du master d informatique, mais aussi à l équipe de la licence de mécanique et à son directeur de l époque qui a su, à sa manière, m orienter vers l informatique. Je remercie à nouveau l équipe enseignante de la licence et du master d informatique, cette fois-ci pour leur aide et leur soutien lors de la découverte de l enseignement universitaire, de l autre côté du miroir. J en profite pour remercier tous les membres de l équipe APR, et en particulier Michèle Soria, que j avais rencontrés en tant qu étudiant, lors des nombreux enseignements auxquels ils participent et qui plus tard lors de mes stages et de ma thèse m ont offert un cadre de recherche chaleureux et dynamique. Je remercie aussi tout le personnel administratif et les ingénieurs chargés de la gestion de nos machines. Je remercie aussi le projet OpenGPU sans qui cette thèse n aurait sans doute pas eu lieu. Merci à tous ses acteurs, et en particulier à Silkan pour la prise de relais. Mes années d études n auraient bien évidemment pas été les mêmes sans Adrien qui m a accompagné de la licence au master et sans qui je n aurais sans doute pas fini la moitié de mes projets. Merci Adrien, pour ta présence, ton écoute et parfois ta patience avec un camarade probablement pas toujours très facile et souvent trop exigeant. Mais surtout, merci pour ta camaraderie et pour ton enthousiasme, qui ne s éteint heureusement pas, une fois passées les douves de Jussieu. Merci ensuite à Benjamin et Philippe que j ai rencontrés lors d un stage de master et que j ai retrouvés plus tard lors de ma thèse. Merci à eux pour m avoir guidé, à leur manière, dans la thèse qu ils découvraient avec un peu d avance sur moi. Je n oublie bien sûr pas les autres membres du bureau 325, Vivien, Guillaume, Étienne, Aurélien, Jérémie et les quelques stagiaires qui sont passés par là. Sans vous, QWOP, GIRP, Isaac, Jamestown et son mode farce, la thèse aurait été plus fade, mais sans moi, Carri et ses GPU l ambiance aurait été plus froide, j en suis sûr.

5 5 Je remercie aussi ceux qui ont su me faire découvrir l informatique d abord en tant que loisir et qui m ont donné envie d aller voir plus loin. Je pense en particulier aux communautés des sites PlayerAdvance et Dev-fr et en particulier à Gregory, alias Mollusk. Merci à vous, et merci à Nintendo et Sony d avoir conçu des machines qui m ont donné l envie d aller voir sous le capot. Enfin, je remercie ma famille qui m a accompagné jusqu ici et qui j en suis sûr me suivra encore à l avenir. Merci à mes parents qui m ont soutenu et qui ont su rester patients lorsqu il le fallait, mais qui m ont aussi toujours poussé à continuer. Merci à ma soeur, qui m a toujours écouté et aidé quand j en avais besoin. Merci à ma belle famille, qui a, elle aussi, su m apporter le soutien dont j avais parfois besoin. Enfin, merci à Sandrine, qui bien qu elle soit passée par là peu de temps avant, a su, à nouveau, vivre une thèse, cette fois-ci du côté de l accompagnant. Merci d avoir joué ce rôle à merveille, associant soutien moral, mais aussi soutien scientifique (merci pour les relectures et les répétitions). Merci d avoir, toi aussi, su me remotiver quand par moment c était difficile. Bien sûr, je remercie tous ceux qui m ont aidé de près ou de loin, qui m ont accompagné, d une manière ou d une autre. Tous ceux qui un jour ont permis que cette thèse soit un moment plus agréable ou qui ont su m apporter leur aide quand j en avais besoin, souvent sans même le savoir.

6 Table des matières Table des matières 6 Table des figures 9 Liste des tableaux 10 Avant-propos 13 1 Introduction 15 I Abstraction et performances I.1 Langages de programmation I.2 Compilation et interprétation I.3 Typage I.4 Programmation parallèle et hautes performances I.5 Bibliothèques de programmation I.6 Conclusion II Cartes graphiques et accélérateurs de calcul II.1 Historique II.2 Processeurs généralistes et accélérateurs de calcul II.3 Outils pour la programmation GPGPU II.4 Applications GPGPU II.5 Outils, bibliothèques et langages III Objectifs et contributions de cette thèse IV Plan de la thèse Langages pour la programmation GPGPU : sémantique opérationnelle et typage 39 I Un langage pour le programme hôte : SPML I.1 Grammaire de SPML I.2 Quelles propriétés pour SPML? I.3 Sémantique opérationnelle de SPML I.4 Propriétés de SPML

7 TABLE DES MATIÈRES 7 II Un langage pour les noyaux de calcul II.1 Quelles propriétés pour Sarek? II.2 Grammaire de Sarek II.3 Sémantique opérationnelle de Sarek II.4 Propriétés de Sarek III Système de types III.1 Environnements et notations III.2 Typage des expressions III.3 Liaison entre SPML et Sarek IV Conclusion Programmation GPGPU : implantation avec OCaml 79 I Choix d implantation I.1 Pourquoi OCaml? I.2 Pourquoi une bibliothèque? II Présentation de la bibliothèque SPOC II.1 Unification des systèmes OpenCL et Cuda II.2 Transferts de données II.3 Exemple de programme SPOC III Noyaux de calcul III.1 Noyaux de calcul externes III.2 Un langage intégré dédié aux noyaux : Sarek III.3 Différences avec le formalisme IV Tests de performance IV.1 Petits exemples IV.2 Bibliothèques optimisées IV.3 Comparaison avec d autres langages de haut niveau IV.4 Calcul multi-gpu V Cas d utilisation : portage du programme PROP V.1 Présentation du programme étudié V.2 Portage avec SPOC V.3 Résultats et performances VI Conclusion Squelettes et composition 117 I Squelettes parallèles pour la programmation GPGPU II Implantation avec des noyaux externes III Implantation avec Sarek IV Exemple d utilisation V Tests de performance VI Conclusion Conclusion générale et perspectives 131 I Conclusion générale

8 8 TABLE DES MATIÈRES II Perspectives II.1 Rapprocher Sarek d OCaml II.2 Squelettes et extensions II.3 Portage vers d autres langages III Perspectives offertes par l évolution du matériel et des systèmes III.1 Évolution matérielle III.2 Cuda 5.5, OpenCL 2.0 : l avenir de la programmation GPGPU IV Vers une programmation GPGPU unifiée A Sémantique opérationnelle de SPML 143 I Grammaire du cœur de SPML II Notations III Sémantique opérationnelle B Comparaison : Cuda, OpenCL et SPOC 147 I Initialisation II Détection des dispositifs compatibles III Initialisation des données IV Préparation du noyau de calcul V Allocation sur le dispositif VI Transfert de données depuis l hôte vers le GPGPU VII Exécution du noyau de calcul VIII Transfert des valeurs de retour vers l hôte IX Utilisation des résultats par l hôte Bibliographie 155 Acronymes 163 Glossaire 164

9 Table des figures 1.1 Grille modélisant l architecture mémoire des GPGPU Cœur de SPML Partie GPGPU de SPML Exemple : programme SPML Grammaire de Sarek Exemple : module Sarek Exemple : noyau de calcul en Sarek Exemple : Programme divergent qui ne termine pas Sarek : Types et environnements de typage Compatibilité des systèmes GPGPU implantés par différents constructeurs Compatibilité système et matérielle de SPOC Type OCaml de la fonction d initialisation Type OCaml d un device Type OCaml de la fonction de création de vecteurs Type OCaml des vecteurs paramétrables Exemple : déclaration d un vecteur paramétré avec OCaml et C Types OCaml des fonctions de transferts explicites Exemple : programme hôte avec transferts automatiques via OCaml et SPOC Exemple : déclaration d un noyau GPGPU avec SPOC Type OCaml de la classe générée pour chaque noyau Compilation dynamique d un noyau GPGPU externe Addition de vecteur avec Sarek Compilation statique de Sarek Compilation dynamique de Sarek Code CudaOpenCL généré depuis un noyau Sarek (fig.3.13) Mesure de performances : Bibliothèques optimisées - Multiplication de matrices Mesure de performances : Comparaison - Addition de vecteurs Mesure de performances : Comparaison - Multiplication de matrices Répartition des tâches sur systèmes multi-gpus

10 3.21 Répartition des tâches et puissance théorique sur systèmes multi-gpus Mesure de performances : PROP - Occupation mémoire cas Grand Définition OCaml de la classe skeleton Définition OCaml d un squelette Map avec un noyau de calcul externe Types OCaml : Fonctions de manipulation des squelettes Exemple : utilisation de Map avec des constructions fonctionnelles Type OCaml : Fonction de compositions Exemple : Squelettes avec Sarek Type OCaml : transformation de noyaux Sarek avec map Transformation de noyaux de calcul Sarek avec des squelettes Exemples : Puissance itérée A.1 Cœur de SPML Liste des tableaux 1.1 Caractéristiques GPU - CPU Comparaison des bandes passantes mémoire de plusieurs architectures Primitives de SPML Opérations mémoire de SPML Variables globales de Sarek dédiées à la programmation GPGPU Bibliothèque d exécution de Sarek Schéma de compilation de Sarek vers IR Extrait de la génération de code Cuda et OpenCL Mesure de performances : temps (en s) et accélérations Meusre de performances : Systèmes Multi-GPU utilisés Mesure de performances : Multi-GPU - Temps (en s) et accélérations Mesure de performances : PROP - Caractéristiques des jeux de données Mesure de performances : PROP - Cas Petit et Moyen Mesure de performances : PROP - Cas Grand Mesure de performances : Puissance itérée

11 5.1 Mesure de performances : Comparaison - architecture multicœur

12

13 Avant-propos Cette thèse porte sur l étude d abstractions performantes pour les cartes graphiques qui sont normalement utilisées pour la gestion de l affichage et le traitement 3D dans les ordinateurs. Elles sont très performantes, mais aussi très spécialisées. Récemment, l usage des cartes graphiques a été détourné pour leur permettre de réaliser des calculs généralistes, normalement effectués par le processeur central de l ordinateur (Central Processing Unit (CPU)). Cette utilisation généraliste des unités de calculs graphiques (General Purpose Graphics Processing Unit (GPGPU) en anglais) demande une programmation spécifique de très bas niveau d abstraction dont le modèle est très proche de celui imposé par le matériel et qui demande de manipuler explicitement de nombreux paramètres matériels (comme la mémoire). Elle implique en particulier de réaliser de nombreux transferts de données entre la mémoire centrale de l ordinateur (associée au processeur central) et la mémoire du GPGPU. Par ailleurs, la programmation GPGPU demande d associer deux types de programmes (i) des programmes hôtes, qui sont exécutés pas le CPU et sont responsables des transferts mémoires et de la gestion des dispositifs GPGPU (qu on appellera simplement GPGPU par la suite), et (ii) des noyaux de calcul, qui sont des programmes assez courts exécutés par le GPGPU. La programmation GPGPU s appuie aujourd hui sur deux principaux systèmes, Compute Unified Device Architecture (Cuda) et Open Compute Language (OpenCL) qui sont très proches, mais incompatibles. Par ailleurs, certains dispositifs matériels ne sont exploitables qu avec l un de ces deux systèmes, ce qui rend difficile le développement d applications portables. Ceci rend l exploitation de l ensemble des performances des ordinateurs d autant plus complexe que ceux-ci sont de plus en plus hétérogènes, associant plusieurs GPGPU, parfois différents les uns des autres. Dans ce contexte, cette thèse s est attachée au développement d outils de haut niveau d abstraction pour la programmation GPGPU afin de la simplifier, tout en maintenant le haut niveau de performance qu elle peut offrir. Plus précisément, nos principaux objectifs étaient de libérer le programmeur de la gestion mémoire imposée par la programmation GPGPU, mais aussi d offrir une solution portable et hétérogène. Pour cela, nous avons tout d abord conçu un langage de programmation dédié à la programmation GPGPU et spécifié son comportement à travers sa sémantique opérationnelle. Par la suite, nous l avons implanté en utilisant le langage de programmation de haut niveau OCaml. Ainsi, la partie hôte correspond à une bibliothèque spécifique pour OCaml, SPOC, qui offre différentes propriétés : 13

14 14 AVANT PROPOS elle unifie les deux systèmes Cuda et OpenCL pour permettre le développement d applications portables, mais aussi hétérogènes, car elle permet de manipuler indifféremment et conjointement tout type de dispositifs GPGPU compatible avec au moins l un des deux systèmes. elle offre des transferts automatiques en associant à certains ensembles de données une information sur leur position dans le système (en mémoire CPU ou en mémoire GPU). Avec cette information, elle réalise automatiquement les transferts dès que les données sont utilisées à une nouvelle position. elle permet de manipuler des noyaux de calcul GPGPU externes, décrits avec les outils des systèmes Cuda ou OpenCL, et ainsi de profiter de bibliothèques de calculs optimisés. Pour accompagner cette bibliothèque, nous avons développé un langage intégré à OCaml, dédié à la description des noyaux de calcul, Sarek. Celui-ci se base sur les langages dédiés aux noyaux de calcul fournis avec les systèmes Cuda et OpenCL, mais avec une syntaxe proche de celle d OCaml et un système de type fort, associé à une vérification statique des types. De plus, ce langage est compilé, à la volée, en noyaux de calcul Cuda ou OpenCL en fonction du type de dispositif chargé d exécuter le noyau. Ainsi, le langage Sarek accroît la dimension portable et hétérogène de notre solution. Bien sûr, nous avons réalisé différents tests de notre solution. D abord, avec de petits exemples, pour vérifier que le niveau de performance était conservé, mais aussi pour vérifier qu elle offre effectivement portabilité et hétérogénéité. Par la suite, nous avons réalisé un portage d une application numérique complexe depuis Fortran et Cuda vers OCaml avec nos outils. Ainsi, nous avons vérifié que l application de nos outils permet effectivement d atteindre un très haut niveau de performance. SPOC et Sarek peuvent donc être utilisés à la fois par des programmeurs OCaml qui souhaitent utiliser des dispositifs GPGPU, mais aussi par la communauté du calcul numérique et plus particulièrement pour du calcul haute-performance. Afin d offrir davantage d abstractions, mais aussi de permettre d offrir des optimisations spécifiques, nous avons développé ces outils en nous attachant à les rendre facilement extensibles. Ainsi, la dernière partie de cette thèse décrit le développement de quelques squelettes de programmation pour la programmation GPGPU. Ces squelettes sont des constructions algorithmiques paramétrables qui permettent d automatiser certains calculs. Là encore, différents tests ont confirmé le haut niveau de performance atteint par notre implantation. Ce travail a été réalisé au Laboratoire d Informatique de Paris 6 (LIP6) de l Université Pierre et Marie Curie (UPMC, Paris), sous la direction des Pr. Emmanuel Chailloux et Jean-Luc Lamotte. Une partie de ces recherches a été réalisée dans le cadre du projet OpenGPU 1 du pôle Systematic. 1.

15 CHAPITRE 1 Introduction «We have in our possession a chip that could revolutionize medicine as we know it, by performing 100 billion operations a second (... ) and then we thought : hay! let s use it for games!» Publicité pour 3dfx Sommaire I Abstraction et performances I.1 Langages de programmation I.2 Compilation et interprétation I.3 Typage I.4 Programmation parallèle et hautes performances I.5 Bibliothèques de programmation I.6 Conclusion II Cartes graphiques et accélérateurs de calcul II.1 Historique II.2 Processeurs généralistes et accélérateurs de calcul II.3 Outils pour la programmation GPGPU II.4 Applications GPGPU II.5 Outils, bibliothèques et langages III Objectifs et contributions de cette thèse IV Plan de la thèse

16 16 CHAPITRE 1. INTRODUCTION

17 I. ABSTRACTION ET PERFORMANCES 17 CETTE THÈSE a pour objet l étude d abstractions performantes pour les cartes graphiques. Avant de présenter la programmation des cartes graphiques il est donc important de discuter des trois notions suivantes : abstractions, performances ainsi que programmation dont découlent les deux premières. I Abstraction et performances I.1 Langages de programmation Les programmes informatiques sont conçus pour s exécuter sur des ordinateurs dont l architecture est complexe. Ces machines ont une unité centrale de calcul (Central Processing Unit - CPU, en anglais) capable d exécuter du code spécifique, lié à leur architecture. Ce langage machine composé de 0 et de 1 représente une suite d instructions et de données à traiter. Il est très éloigné des langages naturels que manipulent les humains, et donc les programmeurs. Afin de simplifier la programmation, des langages de programmation ont été développés. Ces langages ont pour principal objectif d être manipulables par des humains pour décrire les instructions et les données composant un programme et d être exploitables sur des architectures matérielles spécifiques. Un programme exécutable sur une architecture ne sera pas obligatoirement exécutable sur une autre architecture. Le langage natif des machines peut-être considéré comme la méthode la plus concrète de programmer, il est dédié à un type de CPU. Les langages de programmation permettant d offrir davantage d abstractions, c est-à-dire d offrir des constructions plus éloignées des aspects matériels de l ordinateur et de libérer le programmeur de la gestion explicite de ces mêmes propriétés matérielles des ordinateurs, ils sont indépendants du type de CPU. Ils se décomposent en plusieurs catégories qui apportent différents niveaux d abstractions sur le matériel, les instructions des programmes ou sur les données. On s attachera ici au modèle de programmation séquentiel dans lequel un programme exécute l ensemble des instructions qui le composent dans un ordre prédéfini par la structure du programme. La majorité des langages de programmation de ce modèle se répartit en quatre grandes familles : les langages (i)impératifs, (ii)fonctionnels, (iii)orientés objet ou (iv)logiques. Les langages impératifs sont structurés sous forme de séquences d instructions manipulant la mémoire de l ordinateur. C est le modèle le plus proche du fonctionnement des machines. Il s appuie sur la modification (mutation) d états mémoire. Il implique donc souvent de manipuler explicitement les composants de la machine, en particulier la mémoire. Ce paradigme apporte peu d abstractions sur les opérations et la mémoire. Fortran, Pascal ou C sont des exemples de langages impératifs. Les langages fonctionnels permettent d abstraire le modèle d exécution de la machine en manipulant des fonctions plus proches du modèle mathématique. La mémoire n est plus modifiée par les instructions : les programmes sont constitués de fonctions qui via des valeurs d entrée, produisent de nouvelles valeurs en sortie, rejetant ou limitant la mutation des données. Le plus souvent, ils permettent d abstraire une partie des ressources matérielles de la machine, en particulier la mémoire qui y est gérée automatiquement. On citera les langages de la famille Lisp (Scheme, Common Lisp, Le Lisp,... ), ceux de la famille ML (OCaml, SML, F#,... ) et la famille des langages dits «paresseux» ou à évaluation retardée comme LazyML, Miranda ou Haskell comme représentants des langages fonctionnels.

18 18 CHAPITRE 1. INTRODUCTION Les langages orientés objet manipulent des objets, c est-à-dire des ensembles de données et de méthodes s appliquant sur ces données. La combinaison de différents objets permet de structurer le programme. Les langages objets à classe, comme Java, s appuient sur la notion d héritage entre classes pour permettre de spécialiser des parties du code. Les méthodes sont le plus souvent décrites en utilisant les paradigmes impératifs ou fonctionnels. SmallTalk, Java, C++, C#, JavaScript ou Python font partie de la famille des langages orientés objet. La programmation logique définit les programmes comme un ensemble de règles logiques. Ces règles sont ensuite automatiquement appliquées à un ensemble de faits élémentaires pour calculer la sortie du programme. Elle dépend de systèmes automatiques d application des règles. Ces systèmes simplifient la tâche du programmeur, mais peuvent s avérer coûteux en temps de calcul et surtout ne permettent pas de prédire facilement le comportement du programme au cours de son exécution. Le principal langage logique est Prolog. Les langages multiparadigmes permettent d accroître l abstraction en autorisant le programmeur à choisir son modèle de programmation et à en combiner plusieurs au sein d un même programme. Ils offrent souvent les abstractions sur la mémoire des langages fonctionnels tout en autorisant une programmation proche du modèle de la machine. On citera ici les langages OCaml, Python, Scala, Objective C, C++ et Java même si la plupart des langages modernes peuvent intégrer cette famille. I.2 Compilation et interprétation Les programmes écrits avec des langages de programmation sont naturellement incompréhensibles par un ordinateur. Afin de permettre l exécution d un programme par une machine, il est nécessaire d opérer une étape de traduction du langage de programmation vers le langage machine, ou vers des actions décrites en langage machine. Cette traduction peut principalement s opérer de deux manières : par compilation ou interprétation. La compilation consiste à utiliser un outil, le compilateur, capable de traduire l intégralité du programme en langage machine, avant l exécution. L interprétation consiste à utiliser un interprète pour lire le programme en exécutant, directement, au cours de la lecture, les opérations du programme. La méthode choisie peut influer sur la portabilité du programme, cest-à-dire sa capacité à s exécuter sur plusieurs machines d architectures différentes. Afin d exécuter un programme compilé sur plusieurs architectures, il est nécessaire d avoir un ou plusieurs compilateurs capables de cibler ces architectures. De la même manière, il est nécessaire de posséder un interprète pour chaque architecture dans le cas des langages interprétés. En général, l écriture d un interprète est plus simple que celle d un compilateur. Les langages interprétés sont considérés comme plus portables que les langages compilés. En contrepartie, l interprétation entraîne une charge supplémentaire pour l ordinateur et ralentit l exécution du programme. Les programmes compilés seront donc considérés comme plus performants, c est-à-dire qu ils exécuteront un même programme plus rapidement. De plus, la phase de compilation permet d analyser l ensemble du code, pour éventuellement produire un code machine optimisé plus performant. Elle permet aussi de détecter des erreurs avant l exécution du programme. Certains langages sont plus souvent utilisés compilés comme le langage C, tandis que d autres sont plutôt interprétés comme Scheme. Il reste cependant possible de développer des interprètes pour C comme Ch[1] ou TCC[2], ainsi que des compilateurs pour Scheme comme Bigloo[3]

19 I. ABSTRACTION ET PERFORMANCES 19 ou pour Python comme Cython[4]. Les deux approches peuvent aussi être associées. Il est désormais commun de manipuler des langages de programmation compilable vers du code machine ciblant des machines abstraites. Une machine abstraite est un modèle théorique qui représente un processeur et son jeu d instructions. Une machine abstraite ne représente le plus souvent pas un processeur réel. On utilisera alors des interprètes pour exécuter le programme. Ces interprètes vont exécuter le code de la machine abstraite, en utilisant un ensemble d opérations décrites en instructions-machine du processeur réel qui exécute l interprète. On les appelle des machines virtuelles. Cette approche permet de bénéficier de la compilation pour produire un code optimisé et concis tout en profitant des machines virtuelles pour offrir plus de portabilité. Par ailleurs, les interprètes sont désormais souvent capables de compiler des parties de code vers du code natif. Ce système de compilation à la volée (en anglais, jit - just in time) permet d apporter de meilleures performances à certaines sections des programmes interprétés. L utilisation de machines virtuelles capable de compiler du code à la volée permet d obtenir des performances très proches de celles obtenues avec les langages compilés tout en offrant une grande portabilité. On citera, par exemple, Java comme langage compilé pour une machine virtuelle avec compilation JIT. I.3 Typage Afin de garantir davantage de sureté d exécution, la plupart des langages de programmation utilisent des systèmes de types. Les types permettent de faire la différence entre les données, par exemple entre un nombre entier et une chaîne de caractères, mais aussi entre les opérations, une opération sur des nombres entiers sera différente d une opération sur des caractères, et ainsi de limiter l utilisation de ces opérations. Les systèmes de types permettent donc d apporter davantage de contrôle au programmeur sur les données qu il manipule et sur les opérations sur ces données. Les langages de programmation offrent différents systèmes de types, qui varient en fonction du moment où la vérification de type est effectuée (typage statique ou dynamique), et en fonction de la précision de cette vérification (typage faible ou fort). Typage statique et dynamique. Le typage statique vérifie lors de la phase de compilation que le programme est bien typé, c est-à-dire qu il n y a pas d opération sur des valeurs d un type incompatible. Le typage dynamique, au contraire, effectue la vérification au plus tard, lors de l exécution du programme. Au moment de réaliser une opération sur des valeurs, il va s assurer que leurs types sont bien compatibles avec l opération. On considère que le typage statique offre davantage de sécurité. En effet, il permet d assurer au programmeur que son programme ne déclenchera pas à l exécution d erreurs de typage et donc qu il ne s arrêtera pas brusquement pour cette raison. Il permet aussi de s affranchir de la vérification dynamique des types qui entraîne un surcoût en temps de calcul dans l exécution du programme. En contrepartie, il est plus compliqué à mettre en œuvre dans les langages et peut refuser des programmes qui s exécuteraient correctement. Cependant, c est, la plupart du temps, un atout pour les programmeurs, car il permet de détecter, au plus tôt (avant l exécution du programme), beaucoup d erreurs autrement très difficiles à corriger. Les langages C, Java et OCaml sont des langages typés statiquement ; Scheme, Smalltalk ou Python sont des exemples de langages typés dynamiquement.

20 20 CHAPITRE 1. INTRODUCTION Typage faible et fort. Les systèmes de types sont souvent qualifiés de forts ou faibles. Un système de type fort est un système de type qui rejette toute opération sur des données incompatibles. Au contraire, un système de type faible va autoriser certaines opérations sur des types proches des types compatibles. Les systèmes de types forts associés au typage statique sont ceux qui rejetteront le plus de programmes, mais permettront de détecter le maximum d erreur. En contrepartie, un système de type dynamique plus faible permettra au programmeur de contourner les limites du typage pour écrire des instructions autrement interdites. Même avec un système de types fort, il reste possible de définir des fonctions génériques, capables de manipuler différents types de données. Différentes solutions existent pour mettre en place cette généricité comme le polymorphisme ou la surcharge. Le polymorphisme permet de définir des fonctions qui seront compatibles avec tout type de données et pourront renvoyer différents types de données. Par exemple, une fonction de création de couples pourra associer tout type de données et produire un couple, dépendant du type de ses deux paramètres. Elle pourra ainsi associer un nombre entier avec une chaîne de caractères ou bien un caractère seul avec un autre couple. La surcharge permettra par exemple en Java de définir différentes fonctions, ayant le même nom, mais prenant différents types de paramètres, et offrant un traitement différent, en fonction des paramètres. Ainsi, le compilateur, ou l interprète sélectionneront la fonction la plus adaptée en fonction des paramètres utilisés. Parmi les langages typés statiquement on retrouvera des systèmes de types faibles comme avec le langage C et des systèmes de types forts comme avec OCaml. Il en est de même pour les langages typés dynamiquement, Ruby s appuie sur un système de types fort, JavaScript sur un système de types faible. I.4 Programmation parallèle et hautes performances Afin d accélérer matériellement l exécution des programmes, il existe deux principales solutions. (i)augmenter la fréquence d exécution de l unité de calcul (le processeur) et ainsi le nombre d opérations qu il peut effectuer par secondes ou alors (ii)multiplier le nombre d unités de calcul pour permettre l exécution de plusieurs tâches en parallèle. Là où la première solution ne demande aucun travail au programmeur, la seconde demande de correctement exploiter les multiples processeurs et donc d écrire un code spécifique. L augmentation de fréquence a actuellement atteint une limite difficile à franchir (principalement pour des raisons de dissipation de chaleur) et c est donc le parallélisme qui est utilisé désormais pour augmenter les performances. Il existe plusieurs types d architectures parallèles : les systèmes à mémoire partagée et les systèmes distribués. Ces deux systèmes se programment différemment. En mémoire partagée, les différentes unités de calcul partagent un même espace mémoire. Il est nécessaire de s assurer que les différents processeurs n écrivent pas au même moment dans le même emplacement mémoire. En mémoire distribuée, chaque unité de calcul possède son propre espace mémoire. Il est nécessaire d organiser la copie des données entre les différents espaces mémoires. Chaque modèle impose d appliquer des stratégies de synchronisation et d ordonnancement des tâches particulières qui complexifient énormément l écriture des programmes. On peut observer une relation entre architectures parallèles et modèles de programmation. La programmation impérative modifie directement la mémoire et s approche davantage de la mémoire partagée. Au contraire, la programmation fonctionnelle travaille davantage par copie et partage de valeurs et s approche de ce fait des systèmes distribués. De même, on préférera associer

21 I. ABSTRACTION ET PERFORMANCES 21 différents types de calculs à une famille de langages. En particulier, on différenciera le calcul numérique, qui s attache à l approximation numérique de problèmes mathématiques, du calcul symbolique qui s attache à la manipulation d expressions mathématiques. Le premier manipule des ensembles de données de très grande taille dont la copie n est pas envisageable et préférera les langages impératifs à effet de bord, tandis que le second préférera les langages fonctionnels qui travaillent par copie. Dans le cadre de la programmation parallèle, nous distinguerons la programmation dite hauteperformance. En effet, l informatique et la programmation s attachent à de multiples secteurs et on ne programme pas de la même manière des sites internet, des jeux vidéo ou des machines-outils. La programmation haute-performance s attache à l exploitation d architectures particulières pour obtenir les plus hautes performances sur des applications de calcul numérique scientifique. Elle est souvent associée à l utilisation de supercalculateurs. Les supercalculateurs sont des systèmes complexes, souvent composés de multiples ordinateurs (des nœuds) reliés entre eux. Chaque nœud possède lui même une architecture complexe (plusieurs unités de calcul). Ils associent architecture distribuée entre les différents nœuds et partagée au sein de chaque nœud du calculateur. Dans ce cadre, il est commun de cibler une seule architecture (un seul supercalculateur) pour l écriture des programmes. Les programmeurs utilisent alors des outils très proches du langage machine pour exploiter au mieux leur architecture cible. Ce travail d optimisation, souvent réalisé à la main, par des programmeurs experts du domaine et spécialistes de l architecture cible, permet d atteindre un haut niveau de performances des supercalculateurs. Certains programmes sont compatibles avec plusieurs cibles, ceci demande un travail d optimisation supplémentaire pour chaque cible. La portabilité est donc particulièrement difficile (et coûteuse) si on veut maintenir un haut niveau de performances. La programmation haute-performance a donc tendance à s attacher principalement à l optimisation et aux performances limitant l utilisation d outils de haut niveau d abstraction. I.5 Bibliothèques de programmation I.5.a Bibliothèques Les langages de programmation sont souvent accompagnés de bibliothèques. Ces bibliothèques sont des ensembles d opérations utilisables par les programmeurs. Ces opérations permettent de simplifier la programmation ou de profiter d optimisations particulières. Les bibliothèques participent à la montée en abstraction des langages de programmation en réduisant l impact des aspects matériels sur les programmes. Elles permettent d abstraire des opérations en cachant au programmeur toute la complexité qu elles contiennent. Il existe par exemple plusieurs méthodes pour multiplier des matrices, les versions les plus performantes sont très complexes à mettre en œuvre, et nécessitent de maîtriser au plus près l architecture matérielle des ordinateurs. [5, 6] et [7] présentent par exemple des optimisations particulières destinées à accroitre les performances des multiplications de matrices sur une architecture de carte graphique particulière. Néanmoins, de nombreuses bibliothèques existent pour permettre aux programmeurs de profiter de hautes performances dans leur langage favori. On pourra aussi noter que le support des architectures parallèles peut être apporté à un langage à travers des bibliothèques. Par exemple, la bibliothèque Message Passing Interface (MPI)[8], qui existe pour de nombreux langages permet l écriture de programmes ciblant les archi-

22 22 CHAPITRE 1. INTRODUCTION tectures distribuées. De son côté, Open Multi Processing (OpenMP)[9] inclut une bibliothèque pour l écriture de programmes parallèles en mémoire partagée. I.5.b Squelettes algorithmiques Afin de décrire un algorithme complexe, il est commun d appliquer des «recettes» connues. Dans le domaine de l ingénierie logicielle, on appelle ces recettes des patrons de conception (design patterns en anglais). Ils permettent de structurer les programmes pour répondre à un problème donné. Ils peuvent être spécialisés dans la résolution d un calcul complexe ou dans l utilisation d architectures difficiles à exploiter. Pour automatiser leur utilisation et simplifier davantage la tâche des programmeurs, certains patrons ont été transformés en fonctions paramétrables, c est-à-dire des constructions algorithmiques, qui à l aide de certains paramètres pourront reproduire l ensemble du patron sélectionné. Ces constructions algorithmiques, souvent regroupées dans des bibliothèques, sont appelées des squelettes algorithmiques[10, 11, 12, 13]. Il existe deux principaux types de squelettes, les squelettes de données et les squelettes de tâches[14]. Les premiers exploitent des structures de données distribuées entre les unités de calcul pour produire du parallélisme. On pourra citer le squelette map qui à partir d un ensemble de données, applique un même calcul à chaque élément de l ensemble pour produire un nouvel ensemble. Les seconds s appuient sur les relations entre différentes tâches pour paralléliser ce qui peut l être. Par exemple, le squelette pipe associe deux tâches en utilisant le résultat de la première comme données d entrée de la seconde. Les squelettes permettent de simplifier l écriture des programmes, mais aussi de profiter de constructions optimisées pour la résolution de l algorithme qu ils implantent. I.6 Conclusion La notion d abstraction regroupe l ensemble des possibilités offertes aux programmeurs pour s affranchir des notions concrètes liées aux machines. En particulier, l utilisation de langages de programmation permet de s éloigner du langage machine très difficile à manipuler pour un être humain. L utilisation d un langage multiparadigme permet aussi au programmeur de bénéficier d un large choix de méthodes de programmation. L utilisation de compilateurs, d interprètes et de machines virtuelles libère le programmeur de la nécessité d écrire de multiples programmes pour cibler des architectures différentes. Les langages de programmation permettent aussi via les systèmes de type de structurer les données des programmes. Le typage statique vérifie par ailleurs que le programme satisfait les contraintes de type ce qui limite les erreurs. Certains langages apportent davantage d abstractions en offrant une manipulation automatique de composants de la machine, comme la mémoire. Certains offrent aussi des constructions pour simplifier l écriture des programmes et automatiser des tâches autrement plus complexes. Les bibliothèques et squelettes de programmation permettent d accroître encore le niveau d abstraction en s attachant cette fois à l automatisation des calculs et de leur organisation au sein du programme. D un autre côté, la recherche de performance s attache souvent à l optimisation des programmes pour des architectures données. La recherche des performances passe souvent par l utilisation d outils de bas niveau d abstraction, et il est souvent considéré que l utilisation de langages de très haut niveau limite l accès à de bonnes performances, car ils empêchent d optimiser le programme manuellement au plus près du langage machine. En pratique, le domaine de la programmation haute-

23 II. CARTES GRAPHIQUES ET ACCÉLÉRATEURS DE CALCUL 23 performance s attache principalement au calcul numérique et préférera utiliser des langages impératifs avec gestion manuelle de la mémoire. Néanmoins, les bibliothèques de calculs optimisés et les squelettes algorithmiques permettent d aider les programmeurs à obtenir de hauts niveaux de performance sans empêcher l accès aux outils de haut niveau d abstraction. Dans cette thèse, nous verrons que les cartes graphiques ont des architectures très proches de celles des supercalculateurs et que les méthodes de programmations qui leur sont associées sont d assez bas niveau d abstraction. L objectif de cette thèse est donc d étudier le développement d outils de plus haut niveau d abstraction tout en se focalisant sur les performances dans le cadre de la programmation des cartes graphiques. II Cartes graphiques et accélérateurs de calcul Cette thèse a pour objectif l étude d abstractions performantes pour la programmation des cartes graphiques. En effet, les cartes graphiques sont des périphériques complexes à programmer, mais capables de délivrer de très hautes performances. Il paraît donc nécessaire d offrir des outils de haut niveau d abstraction pour simplifier leur utilisation tout en s assurant de conserver un haut niveau de performance. Dans ce cadre, il est important de distinguer les cartes graphiques (Graphics Processing Unit (GPU), en anglais) des CPU, ainsi que les méthodes de programmation qui leur sont associées. Pour ce faire, nous allons dresser un rapide historique des cartes graphiques et de leur programmation. Nous étudierons par la suite le cas plus général des accélérateurs de calcul (dont font partie les cartes graphiques), d une part, car ils sont concurrents des cartes graphiques pour le calcul hautes-performances et d autre part, car les méthodes de programmation qui leur sont associées sont proches et tendent à converger vers des outils communs. II.1 Historique Naissance. Les cartes graphiques ont été développées dans les années 1980 dans le but de soulager les processeurs de la charge que demandaient la gestion de l affichage de texte et, plus tard, la gestion séparée de chaque pixel de l écran. Elles sont des processeurs secondaires connectés au CPU et dotés de leur propre espace mémoire. Avec la demande de plus en plus importante en matière de graphisme incluant de la couleur, des animations et un nombre de pixels à afficher de plus en plus important, les cartes graphiques ont commencé à se perfectionner. Chargées principalement du calcul et du transfert des images produites par l ordinateur vers l écran, elles ont évolué pour permettre l affichage (et le calcul) d images en trois dimensions. La 3D est une activité très coûteuse en calcul, en particulier dans le cas d opérations en temps réel comme dans les jeux vidéo. C est sur ce créneau, et sur celui du dessin assisté par ordinateur qu elles vont se spécialiser. Le jeu vidéo 3D a permis la démocratisation des cartes graphiques en apportant la diffusion de masse et donc la baisse des coûts. Les environnements 3D vont se complexifier, ajoutant des textures aux modèles géométriques. Ces textures, des images à appliquer sur tout ou partie de l environnement 3D, demandent une importante quantité de mémoire ainsi qu une grande vitesse de transfert entre le CPU et la carte graphique. En effet, même si la carte graphique s occupe de l affichage, c est le CPU qui organise les tâches qu elle doit exécuter, et qui définit les données à afficher. L importante demande en matière de jeux vidéo va accélérer l évolution des cartes graphiques,

24 24 CHAPITRE 1. INTRODUCTION leur offrant d un côté plus de capacité de calcul pour davantage d effets en temps réel, et d un autre côté plus de mémoire pour augmenter la quantité d information à traiterafficher à l écran. La bande passante entre le CPU et la carte graphique va elle aussi être augmentée, passant des bus ISAVESA à PCI puis AGP et maintenant PCI-Express. De la même manière, l organisation de la mémoire intégrée dans les cartes graphiques va se hiérarchiser et se complexifier pour offrir des débits de plus en plus importants. Shaders et programmation des cartes graphiques. Bien qu on puisse définir un ensemble de tâches à faire exécuter par la carte graphique, ces tâches restaient prédéfinies et non programmables. La création d effets complexes et non prédéfinis demandait une forte implication du CPU dans les calculs et donc une importante perte de performances. En effet, enfin de proposer davantage de réalisme, les applications 3D ont commencé à intègrer de plus en plus de code numérique issu de la physique (gestion de drapés de vêtements, effet de vent, écoulement d eau, effet de lumière complexes, destruction de décors, etc). Afin de donner plus de flexibilité aux programmeurs et de permettre davantage d effets graphiques sans exploiter les CPU, la société Pixar définit en 1988 un langage, le shading language[15], pour décrire des opérations manipulant des éléments 3D depuis le GPU, des shaders. Un shader est un programme dédié au traitement graphique, qui sera exécuté par la carte graphique. Il permet de manipuler les données graphiques (pixel, vertex) directement depuis la carte graphique et de profiter des multiples unités de calcul qu elle possède. D abord dédiés à la génération d effets visuels précalculés, les shaders ont fini par devenir des programmes utilisables en temps réel. Différentes implantations de shading language ont vu le jour. Les trois principales étant HLSL (High Level Shader Language)[16] proposé par Microsoft dans son Application Programming Interface (API) Direct3D, OpenGL Shading Language (GLSL)[17] proposé par l OpenGL Architecture Review Board dans l API Open Graphic Library (OpenGL) et Cg (C for Graphics)[18] proposé par l entreprise NVidia. Ces trois langages, très proches du langage C, permettent la manipulation de pixels, textures et modèles 3D depuis la carte graphique, en temps réel. NVidia a proposé en 2001 la première carte graphique grand public capable d exploiter des shaders, via des unités de calcul dédiées, la Geforce 3. On distingue trois familles de shaders, les vertex shaders qui manipulent la position des points des éléments 3D dans l espace, les geometry shaders qui manipulent directement des ensembles de points et les pixel shaders qui manipulent les couleurs à afficher. Ces trois types de shaders sont appliqués les uns après les autres au sein du pipeline des cartes graphiques. Ceci a poussé à l ajout d unités de calcul supplémentaires, dédiées aux shaders, dans les cartes graphiques et a permis un accès simplifié au pipeline graphique pour les programmeurs. En effet, il est alors devenu possible de décrire des séries d opérations à réaliser sur les cartes graphiques et de combiner ces opérations entre elles. Les cartes graphiques sont depuis constituées de nombreuses unités de calcul et possèdent un espace mémoire important. C est avec l arrivée d unités de calcul sur les valeurs flottantes sur les cartes graphiques qu on a commencé à s intéresser à leur utilisation pour la résolution de problèmes numériques. En effet, nombre d entre eux sont modélisables sous la forme de calculs à réaliser sur des matrices. Or c est justement ce que permettent de faire les shading languages, et ce, avec des performances parfois nettement supérieures à celle des CPU classiques. La programmation généraliste sur unité de calcul graphique (GPGPU) était née.