On sait déjà qu’on n’atteindra pas l’exascale en multipliant le nombre et la densité des composants d’aujourd’hui. Avant d’envisager l’avenir, encore faut-il comprendre pourquoi.

Cet article fait partie du dossier En route vers l’exascale

De l’avis général, on est en fin de cycle. Les composants qui font la performance et l’efficacité énergétique des plateformes HPC dérivent déjà de longs travaux d’optimisation, de sorte qu’aucun progrès décisif n’est à l’ordre du jour. Il en va de même au niveau plus global des architectures. On pourra sans doute pousser les designs actuels un peu plus loin, mais certainement pas les amener tels quels à l’échelle supérieure. Ajoutez à cela l’obsolescence croissante d’un parc applicatif parfois pluri-décadaire, les impasses de programmabilité pour un nombre de cœurs multiplié par 100 (au minimum), l’explosion du volume des données à gérer en pré- ou post-traitement… et vous avez une idée de la difficulté des défis à relever.

Loi de Moore contre loi de Dennard

Au niveau matériel, trois problèmes majeurs. D’abord, il y a la concurrency. La loi de Moore continuera probablement de s’appliquer d’ici à la fin de la décennie, avec en fin de course des géométries VLSI qui pourraient descendre jusqu’à 5 nanomètres. Mais elle se heurte déjà à une autre “loi”, celle de Dennard, qui veut que les niveaux de voltage et d’intensité restent proportionnels aux dimensions linéaires des transistors. Le résultat probable de cette impasse, ce sont des processeurs plans et 3D opérant à des fréquences d’horloge progressivement réduites, ne serait-ce que pour que leur consommation électrique reste contenue. Il va donc falloir les multiplier. Plus personne n’est surpris quand on évoque le chiffre de plusieurs centaines de millions d’ALUs (Arithmetic Logic Unit) dans une plateforme exascale type. En revanche, si l’on considère que plusieurs threads par ALU sont nécessaires pour masquer les latences mémoire et réseau, on aboutit à un nombre d’opérations simultanées supérieur de plusieurs ordres de magnitude à ce que l’on sait programmer aujourd’hui.

La fiabilité de tels systèmes ajoute d’autres difficultés à la conception d’architectures exascale. Compte tenu du MTTF (Mean Time To Failure) des composants actuels, une plateforme de classe exa gérée de façon classique aurait une durée de vie comprise entre une minute et une heure. Dans ce domaine, l’amélioration des procédés industriels ne suffira pas. La nature multiplicative de la fiabilité implique des mécanismes globaux de résilience matérielle qu’on ne maîtrise pas encore, et qui de plus nécessitent de nouvelles méthodes de contrôle au niveau logiciel.

S’il est établi que ce sont les applications qui devront s’adapter, et cela à partir de mécanismes autrement plus sophistiqués que de simples checkpoints obligeant le cas échéant à recommencer certains calculs intermédiaires, encore faut-il que la logique électronique suive. Pour finir, n’oublions pas que le comportement des transistors va s’avérer de plus en plus probabiliste. La marge de bruit va en effet se restreindre considérablement du fait de la réduction des voltages et de la largeur des canaux internes. Il va falloir faire avec cela aussi.

50 Gflops / Watt

Troisième grande difficulté découlant du passage à l’échelle, l’efficacité énergétique. En partant des standards actuels, un système exascale pourrait consommer jusqu’à 100 MW. Evidemment, ce n’est pas envisageable. Quel responsable politique aurait même l’ingénuité de plaider pour qu’on alloue à un tel système son propre réacteur nucléaire ? On parvient aujourd’hui à des taux d’efficacité atteignant 2 Gflops/Watt, soit 500 pJ/flop. L’objectif, pour que l’exascale soit soutenable du point de vue de l’alimentation  électrique et du coût d’exploitation, c’est un accroissement d’environ 25X, qui porterait l’efficacité des systèmes à 50 Gflops/Watt (ou 20 pJ/flop).

Naturellement, on n’atteindra pas ces chiffres par les seuls progrès de l’ingénierie des semi-conducteurs. D’ici 2020, celle-ci n’est censée apporter qu’un facteur d’amélioration compris entre 2 et 4. Il faut donc trouver d’autres voies – le pluriel n’est ici pas de trop – pour économiser l’énergie. Parmi les pistes envisagées, comme nous le verrons plus en détails dans la suite de ce dossier, citons l’hybridation forte des clusters avec des composants très basse consommation, la réduction de l’espace mémoire alloué à chaque flop, la réduction partout où c’est possible des transferts de données, ou encore l’extinction automatique de processeurs dédiés à certaines tâches (CPUs, GPUs, ASICs, FPGAs…) en fonction du niveau d’achèvement des applications.

L’impasse logicielle

Dernier problème (mais non des moindres), la programmabilité évoquée plus haut. Pour atteindre 10^18 flops, les obstacles logiques sont considérables. Si l’on considère que 10 milliards de threads sont nécessaires pour utiliser pleinement 100 millions de cœurs, d’autres méthodes de programmation doivent être inventées. Pour des raisons de praticité immédiate, les utilisateurs disposeront très certainement de solutions de compatibilité descendante pour leurs codes MPI. Mais il ne s’agira que d’une ultime étape, quasiment une voie sans autre issue, qui démontre dès à présent que le duo MPI + C/Fortran ne convient plus à cette échelle.

Ce problème touchant à peu près tout le monde, de nombreux travaux sont en cours qui, dans leur majorité, ciblent l’implémentation du parallélisme à un plus haut niveau. Afin de libérer développeurs et scientifiques des contraintes de conception et de codage, une des idées les plus largement exploitées consiste à leur permettre de spécifier leurs algorithmes de façon descriptive, en exposant le parallélisme des traitements et l’affinité des données, puis à laisser des automates mapper finement l’ensemble sur les ressources disponibles.

Des solutions au cas par cas

Autre approche, paralléliser… le parallélisme. Dans cette optique, on est obligé de procéder application par application, ce qui limite le rythme des publications, mais les résultats peuvent s’avérer prometteurs. Par exemple, une équipe chinoise de l’Université de Défense de Changsha travaille actuellement à ré-architecturer plusieurs codes de simulation moléculaire dans le sens d’une triple parallélisation des tâches (via une distribution adaptée sur CPUs et accélérateurs), des threads (via un mécanisme de multi-threading ordonnancé dynamiquement) et des données (via l’utilisation des jeux d’instructions SIMD).

Génériques ou au cas par cas, le fait que ces recherches aient déjà débuté n’est pas un hasard : une fois aboutis, la mise à jour des applications candidates à l’exascale prendra beaucoup de temps. Dans l’intervalle, de nombreuses recherches sur les architectures matérielles, sur l’adaptation des composants et sur des technologies de rupture sont elles aussi en cours. C’est ce que nous vous invitons à découvrir en détail dans la suite de ce dossier.