{"id":346,"date":"2020-04-25T11:46:31","date_gmt":"2020-04-25T09:46:31","guid":{"rendered":"https:\/\/project.inria.fr\/emergences\/?p=346"},"modified":"2020-12-15T11:50:59","modified_gmt":"2020-12-15T10:50:59","slug":"unifier-la-programmation-sur-les-processeurs-multicoeurs-heterogenes-le-defi-de-caroline-collange","status":"publish","type":"post","link":"https:\/\/project.inria.fr\/emergences\/unifier-la-programmation-sur-les-processeurs-multicoeurs-heterogenes-le-defi-de-caroline-collange\/","title":{"rendered":"Unifier la programmation sur les processeurs multic\u0153urs h\u00e9t\u00e9rog\u00e8nes : le d\u00e9fi de Caroline Collange"},"content":{"rendered":"

Pour satisfaire des exigences toujours plus fortes en rapidit\u00e9 et en puissance, l’industrie adopte des processeurs h\u00e9t\u00e9rog\u00e8nes o\u00f9 voisinent maintenant deux types de circuits optimis\u00e9s pour des t\u00e2ches diff\u00e9rentes. Probl\u00e8me : chacun utilise un mod\u00e8le de programmation sp\u00e9cifique non compatible avec l’autre. Scientifique au centre Inria Rennes \u2013 Bretagne Atlantique et laur\u00e9ate d’une bourse Jeune Chercheuse attribu\u00e9e par l’Agence nationale de la recherche, Caroline Collange veut introduire un jeu d’instructions unique qui permettrait d’unifier la programmation, am\u00e9liorant au passage la performance g\u00e9n\u00e9rale et l’efficacit\u00e9 \u00e9nerg\u00e9tique. <\/span><\/strong><\/p>\n

\n
\"\"<\/a>

\u00a9 Inria \/ Photo S. Er\u00f4me – Signatures<\/p><\/div>\n

\n
\n
\n
\n

Toujours plus de calculs et toujours plus vite. Pour les processeurs, la course ne s’arr\u00eate jamais. Les derniers mod\u00e8les sont dits \u201ch\u00e9t\u00e9rog\u00e8nes<\/em>\u201d. Ils embarquent deux familles de circuits. D’une part, un processeur CPU multic\u0153ur scalaire qui effectue des op\u00e9rations de fa\u00e7on s\u00e9quentielle, donc les unes apr\u00e8s les autres. Et d’autre part, un GPU. Con\u00e7u au d\u00e9part pour acc\u00e9l\u00e9rer l’affichage, ce processeur graphique affectionne les op\u00e9rations massivement parall\u00e8les. De fil en aiguille, il est devenu aussi tr\u00e8s pratique pour effectuer du calcul g\u00e9n\u00e9raliste. On appelle cela du \u00ab\u00a0GPGPU\u00a0\u00bb. Selon la nature des t\u00e2ches \u00e0 r\u00e9aliser, les calculs sont orient\u00e9s vers l’une ou l’autre de ces deux zones. Voil\u00e0 pour le paysage actuel.<\/p>\n

Petit b\u00e9mol : 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\u00e9rer deux architectures de jeux d’instructions (ce que l’on appelle les ISA). Difficile dans ces conditions d’optimiser la r\u00e9partition des t\u00e2ches et la performance sans que la programmation ne tourne au cauchemar.<\/p>\n

\n
\n
\n

Garder un seul mod\u00e8le de programmation<\/span><\/h2>\n<\/div>\n
\n
\n

Comment sortir de l’orni\u00e8re ? \u00ab\u00a0En gardant un seul mod\u00e8le de programmation, un seul jeu d’instructions sur un mat\u00e9riel o\u00f9 l’on pourra choisir d’utiliser des c\u0153urs tourn\u00e9s soit vers la performance s\u00e9quentielle soit vers la performance parall\u00e8le\u00a0\u00bb,<\/em>\u00a0explique Caroline Collange<\/strong>. La premi\u00e8re d\u00e9livre de faibles temps de latence. La deuxi\u00e8me permet de traiter de gros volumes. La chercheuse pr\u00e9voit en l’occurrence de conserver \u00ab\u00a0le jeu d’instructions du CPU mais avec le mod\u00e8le d’ex\u00e9cution du GPU.\u00a0\u00bb<\/em><\/p>\n

En pratique, la programmation pourra se faire par le biais de tout environnement de programmation parall\u00e8le pour CPU, par exemple OpenMP<\/em>. On gagne ainsi en souplesse et en compatibilit\u00e9.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n

Regrouper les op\u00e9rations identiques<\/span><\/h2>\n<\/div>\n
\n
\n

Pierre angulaire de cette nouvelle approche : la vectorisation dynamique \u00e0 l’ex\u00e9cution des threads <\/em>au niveau de la microarchitecture. \u00ab\u00a0La vectorisation consiste \u00e0 regrouper des <\/em>threads effectuant des op\u00e9rations 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\u00f4le n’a lieu qu’une seule fois. En factorisant ainsi des op\u00e9rations tr\u00e8s redondantes, on fait dispara\u00eetre le co\u00fbt de gestion scalaire.\u00a0\u00bb<\/em>\u00a0La vectorisation s’effectuera d\u00e9sormais de mani\u00e8re transparente, sans intervention du compilateur.<\/p>\n

L’id\u00e9e de regrouper les op\u00e9rations identiques effectu\u00e9es sur des donn\u00e9es diff\u00e9rentes n’est pas nouvelle : Ada Lovelace l’avait d\u00e9j\u00e0 eue d\u00e8s 1842 ! Et c’est un principe cl\u00e9 des GPU actuels. Mais avec nos travaux, on pourra appliquer pour la premi\u00e8re fois la vectorisation entre threads <\/em>\u00e0 des jeux d’instructions g\u00e9n\u00e9ralistes.<\/p><\/blockquote>\n

Ainsi, les threads <\/em>pourront migrer en toute souplesse d’un type de c\u0153ur \u00e0 un autre.<\/p>\n

L’innovation portera aussi sur l’acc\u00e8s m\u00e9moire. \u00ab\u00a0Les programmes optimis\u00e9s pour les GPU font en sorte que les <\/em>threads acc\u00e8dent \u00e0 des donn\u00e9es cons\u00e9cutives dans la m\u00e9moire. Mais sur les CPU, actuellement, cela ne fonctionne pas comme cela : chaque <\/em>thread travaille dans son coin. Donc, quand on va centraliser les <\/em>threads on va se retrouver avec des\u00a0 emplacements qui sont physiquement \u00e9loign\u00e9s les uns des autres. Ce n’est pas efficace. Par cons\u00e9quent, il faut introduire une couche d’abstraction pour rapprocher physiquement en m\u00e9moire les donn\u00e9es qui sont logiquement \u00e9loign\u00e9es.\u00a0\u00bb<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n

Facteur 10<\/span><\/h2>\n<\/div>\n
\n
\n

Quels gains esp\u00e9rer ?\u00a0\u00ab\u00a0Cela va d\u00e9pendre 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 \u00e0 r\u00e9\u00e9crire le code, sans avoir un surco\u00fbt \u00e0 payer.\u00a0\u00bb<\/em><\/p>\n

Et c’est l\u00e0 l’une des forces du projet.<\/p>\n

Actuellement, les industriels d\u00e9pensent beaucoup d’argent pour ces multiples programmations. G\u00e9n\u00e9raliser le mod\u00e8le d’ex\u00e9cution permettrait de r\u00e9duire ces frais.<\/em><\/p><\/blockquote>\n

Un fabricant de t\u00e9l\u00e9phones pourrait aussi, par exemple, acc\u00e9l\u00e9rer la mise sur le march\u00e9 des nouveaux produits. Cerise sur le g\u00e2teau : ces t\u00e9l\u00e9phones b\u00e9n\u00e9ficieraient indirectement d’une meilleure autonomie car, en regroupant les threads<\/em>, la vectorisation dynamique engendre une baisse de la d\u00e9pense \u00e9nerg\u00e9tique.<\/p>\n

Ces travaux pourraient donner lieu \u00e0 d\u00e9p\u00f4t de brevet sur l’architecture mat\u00e9rielle. \u00ab\u00a0Par ailleurs, nous souhaitons aussi nous int\u00e9resser \u00e0 la compilation. Nous pourrions proposer des optimisations sp\u00e9cifiques \u00e0 la vectorisation dynamique entre <\/em>threads. Par exemple restructurer les boucles pour permettre davantage d’op\u00e9rations identiques entre diff\u00e9rents <\/em>threads. La difficult\u00e9 est de savoir quand appliquer ces transformations. Parfois c’est b\u00e9n\u00e9fique. Parfois non. Il nous faudra d\u00e9velopper des analyses statiques pour permettre au compilateur de prendre la bonne d\u00e9cision au cas par cas.\u00a0\u00bb<\/em><\/p>\n

Des tests sur simulateurs permettront d’\u00e9valuer plus pr\u00e9cis\u00e9ment l’ensemble de ces pistes. Le projet qui vient de d\u00e9buter va s’\u00e9tendre sur 42 mois. \u00ab\u00a0L’ANR va financer deux ans de postdoctorat et une th\u00e8se. Nous sommes d’ailleurs \u00e0 la recherche d’un \u00e9tudiant de th\u00e8se pour la rentr\u00e9e 2020.\u00a0\u00bb<\/em><\/p>\n\n\n\n
\n