6.3 Une nouvelle cible pour FREIA
6.3.4 Limitations
En mettant bout-à-bout les trois pièces du puzzle — la bibliothèque d’agents de traitement d’images, le générateur de code Sigma-C et l’environnement d’exécution entre hôte et accélérateur —, il devient possible d’exécuter des applications FREIA directement sur la puce MPPA. Cependant, l’approche suivie souffre de plusieurs limitations, la plupart inhérentes à l’utilisation du langage Sigma-C.
En effet, Sigma-C a besoin de connaître les quantités de données produites et consom- mées entre deux agents à la compilation. Pour faciliter l’implémentation des opérateurs au voisinage, ainsi que pour diminuer le nombre de transitions entre états dans nos agents, nos agents échangent des lignes d’images. De plus, les agents morphologiques traitent sépa- rément les première et dernière lignes d’une image. Ceci implique que les dimensions des images doivent être connues à la compilation des applications.
Le Sigma-C ne supporte pas les structures de contrôle dynamiques comme les boucles avec des conditions dépendantes des données. Il est également difficile d’activer différents subgraphs indépendants à la demande. Pour contourner ces limitations, nous avons introduit notre environnement d’exécution qui reproduit les structures de contrôle de l’application initiale non supportées par Sigma-C. Nous avons donc au final deux exécutables qui commu- niquent au travers de pipes Unix, ceci rajoutant une couche de complexité supplémentaire afin de pallier les carences de Sigma-C.
En outre, les agents Sigma-C, dont le nombre dépend de l’application compilée, sont placés à raison d’un ou deux par cœur de calcul sur les clusters du MPPA. Plus précisément, le nombre d’agents par cœurs est précisé au travers d’une option de compilation. L’occupation des différents cœurs dépend donc du nombre d’opérateurs de l’application exécutée. Dans l’idéal, une application doit donc comporter autour de 250 opérateurs, de sorte à occuper le maximum de cœurs disponibles. De plus, lorsqu’une application dispose de plusieurs subgraphs indépendants, ceux-ci sont placés en même temps sur le MPPA, ce qui réduit d’autant les ressources disponibles à un instant donné de l’exécution. Les applications les
6. Le modèle flot de données
plus performantes minimisent en effet le nombre de subgraphs utilisés.
Enfin, nous avons également été contraints de contourner les limitations du matériel, notamment au niveau de l’accès à la mémoire globale attachée aux clusters d’entrée/sortie. Nous espérons que la puce de 2egénération « Bostan » aura corrigé ce problème, bien que
nous sommes dans l’incapacité de le déterminer.
6.4 Conclusion
Introduit dans les années 1970, le modèle flot de données facilite l’expression du parallé- lisme des applications destinées aux architectures multicœurs et manycore actuelles.
Le langage Sigma-C, développé pour tirer parti du processeur MPPA de Kalray, est un langage flot de données qui reprend la syntaxe du langage C. Sigma-C permet d’abstraire les communications entre l’hôte et l’accélérateur, ainsi qu’entre les différents nœuds de calcul qui composent le MPPA. Il permet ainsi de facilement tirer parti de l’architecture complexe du MPPA, au prix d’une réécriture complète des applications dans ce langage.
Nous avons créé un pont entre FREIA et Sigma-C, au travers d’une bibliothèque d’opéra- teurs de base de traitement d’images, d’un environnement d’exécution, qui gère les transferts entre hôte et accélérateur et les subgraphs Sigma-C, et d’un générateur automatique de code. Deux algorithmes issus de ce dernier sont ici détaillés. De la sorte, une application FREIA est automatiquement convertie en Sigma-C et peut s’exécuter sur le processeur MPPA. Nous augmentons ainsi le nombre de cibles logicielles et améliorons la portabilité des applications FREIA.
Cette nouvelle chaîne de compilation a permis de réaliser des expérimentations sur notre ensemble de test et, ainsi, de comparer le code Sigma-C exécuté sur MPPA ou sur un processeur conventionnel. Nous montrons que Sigma-C semble mieux exploiter le parallélisme des 256 cœurs du MPPA, particulièrement dans le cas des applications contenant des pipelines profonds de filtres morphologiques. Différentes optimisations nous ont permis d’améliorer les performances de ces applications ou de réduire leur empreinte mémoire. On peut notamment citer le déroulement des boucles convergentes, l’agrégation des agents arithmétiques ou bien l’évaluation partielle des cœurs de boucle morphologiques.
Chapitre
7
L’approche GPGPU : le framework
OpenCL
How beautiful are your feet In sandals, O prince’s daughter Your navel is a bowl
Well-rounded with no lack of wine Your belly, a heap of wheat Surrounded with lilies Your breasts,
Clusters of grapes Your breath,
Sweet-scented as apples
Nobody’s gonna love you the way I love you.
— Song of Songs 7
L
’introduction des accélérateurs graphiques dans les années 1990 a permis de décharger le processeur principal des calculs graphiques, simples et très répétitifs. Ces processeurs graphiques, aussi connus sous le nom de GPU (« Graphics Processing Unit »), ont conduit à des évolutions majeures dans le domaine de la 3D, au point que tous les ordinateurs modernes en contiennent.La réserve de performance de ces processeurs spécialisés a longtemps intéressé les développeurs, qui souhaitaient y exécuter des calculs autres que graphiques. C’est ainsi que sont apparus les langages pour architectures hétérogènes permettant de déporter des calculs génériques sur accélérateurs graphiques, dont CUDA [37] et OpenCL [60] sont aujourd’hui les principaux représentants. Ce paradigme de programmation, appelé GPGPU pour « General-
Purpose Computing on Graphics Processing Units », consiste à profiter des capacités des
accélérateurs graphiques pour diminuer les coûts d’exécution de certains calculs.
Aujourd’hui, les processeurs graphiques sont concurrencés par l’émergence des proces- seurs manycore. Ces derniers disposent de moins d’unités de calcul — environ un ordre de grandeur en moins — qui compensent leur infériorité numérique par une complexité accrue et une meilleure efficacité énergétique globale. Le processeur MPPA de Kalray [43] supporte ainsi ce paradigme à travers la spécification OpenCL, de sorte à pouvoir exécuter directe- ment des applications destinées à des accélérateurs matériels respectant la spécification. Le
7. L’approche GPGPU : le framework OpenCL
projet FREIA [15] dispose, quant à lui, d’une cible logicielle OpenCL. Il a donc été possible, avec quelques modifications mineures, d’exécuter des applications FREIA sur le MPPA pour ainsi comparer l’efficacité de cet accélérateur face à des processeurs graphiques spécialisés. Dans ce chapitre, nous décrivons dans les section 7.1 et section 7.2 les caractéristiques des processeurs graphiques, ainsi que quelques outils servant à les programmer. En section 7.3, nous examinons ensuite les détails de l’implémentation OpenCL de FREIA. Enfin, dans la section 7.4, nous listons les modifications nécessaires afin de l’adapter au processeur MPPA de Kalray, puis nous comparons ce dernier à plusieurs autres accélérateurs OpenCL, à code applicatif identique, pour ainsi tester les performances de notre accélérateur manycore.
7.1 Les processeurs graphiques, des puces spécialisées
Démocratisées dans les années 1990, les cartes d’accélération graphiques améliorent significativement les calculs graphiques. Leur architecture diffère de celle des processeurs centraux : ils sont très adaptés aux calculs simples et répétitifs, par exemple des opérations entières sur les pixels d’une image 2D ou 3D. Avec le temps, ils ont acquis certaines capacités réservées aux processeurs centraux, comme les calculs sur nombres à virgule flottante double précision, ce qui en a fait des accélérateurs de choix pour les calculs scientifiques. Les proces- seurs graphiques ont notamment contribué à l’avènement des architectures hétérogènes, où le processeur principal déporte certains calculs spécifiques vers un ou plusieurs accélérateurs dédiés.