Pour satisfaire des exigences toujours plus fortes en rapidité et en puissance, l’industrie adopte des processeurs hétérogènes où voisinent maintenant deux types de circuits optimisés pour des tâches différentes. Problème : chacun utilise un modèle de programmation spécifique non compatible avec l’autre. Scientifique au centre Inria Rennes – Bretagne Atlantique et lauréate d’une bourse Jeune Chercheuse attribuée par l’Agence nationale de la recherche, Caroline Collange veut introduire un jeu d’instructions unique qui permettrait d’unifier la programmation, améliorant au passage la performance générale et l’efficacité énergétique.
© Inria / Photo S. Erôme – Signatures
Toujours plus de calculs et toujours plus vite. Pour les processeurs, la course ne s’arrête jamais. Les derniers modèles sont dits “hétérogènes”. Ils embarquent deux familles de circuits. D’une part, un processeur CPU multicœur scalaire qui effectue des opérations de façon séquentielle, donc les unes après les autres. Et d’autre part, un GPU. Conçu au départ pour accélérer l’affichage, ce processeur graphique affectionne les opérations massivement parallèles. De fil en aiguille, il est devenu aussi très pratique pour effectuer du calcul généraliste. On appelle cela du « GPGPU ». Selon la nature des tâches à réaliser, les calculs sont orientés vers l’une ou l’autre de ces deux zones. Voilà pour le paysage actuel.
Petit bémol : on ne programme pas un GPU comme on programme un CPU scalaire. Les industriels doivent donc faire cohabiter cahin caha deux univers logiciels pour gérer deux architectures de jeux d’instructions (ce que l’on appelle les ISA). Difficile dans ces conditions d’optimiser la répartition des tâches et la performance sans que la programmation ne tourne au cauchemar.
Garder un seul modèle de programmation
Comment sortir de l’ornière ? « En gardant un seul modèle de programmation, un seul jeu d’instructions sur un matériel où l’on pourra choisir d’utiliser des cœurs tournés soit vers la performance séquentielle soit vers la performance parallèle », explique Caroline Collange. La première délivre de faibles temps de latence. La deuxième permet de traiter de gros volumes. La chercheuse prévoit en l’occurrence de conserver « le jeu d’instructions du CPU mais avec le modèle d’exécution du GPU. »
En pratique, la programmation pourra se faire par le biais de tout environnement de programmation parallèle pour CPU, par exemple OpenMP. On gagne ainsi en souplesse et en compatibilité.
Regrouper les opérations identiques
Pierre angulaire de cette nouvelle approche : la vectorisation dynamique à l’exécution des threads au niveau de la microarchitecture. « La vectorisation consiste à regrouper des threads effectuant des opérations de type similaire, par exemple des additions. L’avantage, c’est qu’ainsi, on ne lit l’instruction qu’une seule fois. Tout ce qui est traitement et contrôle n’a lieu qu’une seule fois. En factorisant ainsi des opérations très redondantes, on fait disparaître le coût de gestion scalaire. » La vectorisation s’effectuera désormais de manière transparente, sans intervention du compilateur.
L’idée de regrouper les opérations identiques effectuées sur des données différentes n’est pas nouvelle : Ada Lovelace l’avait déjà eue dès 1842 ! Et c’est un principe clé des GPU actuels. Mais avec nos travaux, on pourra appliquer pour la première fois la vectorisation entre threads à des jeux d’instructions généralistes.
Ainsi, les threads pourront migrer en toute souplesse d’un type de cœur à un autre.
L’innovation portera aussi sur l’accès mémoire. « Les programmes optimisés pour les GPU font en sorte que les threads accèdent à des données consécutives dans la mémoire. Mais sur les CPU, actuellement, cela ne fonctionne pas comme cela : chaque thread travaille dans son coin. Donc, quand on va centraliser les threads on va se retrouver avec des emplacements qui sont physiquement éloignés les uns des autres. Ce n’est pas efficace. Par conséquent, il faut introduire une couche d’abstraction pour rapprocher physiquement en mémoire les données qui sont logiquement éloignées. »
Facteur 10
Quels gains espérer ? « Cela va dépendre du contexte, des applications, etc. Nous serons quelque part entre la performance du CPU et celle du GPU, si possible plus proche du GPU. Actuellement, entre les deux, il y a un facteur 10. Nous pourrions nous situer dans ces ordres de grandeur, mais sans avoir à réécrire le code, sans avoir un surcoût à payer. »
Et c’est là l’une des forces du projet.
Actuellement, les industriels dépensent beaucoup d’argent pour ces multiples programmations. Généraliser le modèle d’exécution permettrait de réduire ces frais.
Un fabricant de téléphones pourrait aussi, par exemple, accélérer la mise sur le marché des nouveaux produits. Cerise sur le gâteau : ces téléphones bénéficieraient indirectement d’une meilleure autonomie car, en regroupant les threads, la vectorisation dynamique engendre une baisse de la dépense énergétique.
Ces travaux pourraient donner lieu à dépôt de brevet sur l’architecture matérielle. « Par ailleurs, nous souhaitons aussi nous intéresser à la compilation. Nous pourrions proposer des optimisations spécifiques à la vectorisation dynamique entre threads. Par exemple restructurer les boucles pour permettre davantage d’opérations identiques entre différents threads. La difficulté est de savoir quand appliquer ces transformations. Parfois c’est bénéfique. Parfois non. Il nous faudra développer des analyses statiques pour permettre au compilateur de prendre la bonne décision au cas par cas. »
Des tests sur simulateurs permettront d’évaluer plus précisément l’ensemble de ces pistes. Le projet qui vient de débuter va s’étendre sur 42 mois. « L’ANR va financer deux ans de postdoctorat et une thèse. Nous sommes d’ailleurs à la recherche d’un étudiant de thèse pour la rentrée 2020. »
|
