Depuis une dizaine d’années, les systèmes et architectures HPC se sont diversifiés, et avec eux les modèles de programmation. Comment, dès lors, pérenniser les parcs applicatifs et assurer la portabilité des codes ?

C’est effectivement un enjeu que le SRA ETP4HPC a clairement identifié. Il nous semble aujourd’hui nécessaire de mettre en place un certain nombre d’API permettant d’optimiser les aspects applicatifs et les aspects exécution. Ces API, intervenant aux niveaux des modèles de programmation et des runtimes, vont vite devenir indispensables à une exploitation optimale des ressources. Il y a également un défi sur les I/O car les architectures I/O vont beaucoup évoluer. Le modèle mémoire / disques va sans doute être remis en cause à moyen terme, au moins sur les grands systèmes, en raison des différentiels de temps d’accès. Nous avons besoin de niveaux intermédiaires dans la hiérarchie du stockage, et de plus d’intelligence dans la façon dont les données sont traitées.

Concrètement, ces API devront par exemple permettre aux développeurs applicatifs de spécifier pourquoi et à quels moments ils accèdent aux données. Ajouter un peu de sémantique aide les fournisseurs de solutions middleware et matérielles à optimiser les transports de données dans les architectures. Ces transports sont importants à la fois pour la performance et pour l’efficacité énergétique. Transporter les données dans un système HPC à très grande échelle consomme une partie non négligeable de l’enveloppe énergétique globale.

La gestion de la résilience est un autre exemple où l’émergence d’API est importante. Les développeurs applicatifs savent quelles données conserver et ce qui est nécessaire pour reprendre en cas de défaillance. Il faut avoir la capacité de le spécifier et d’implémenter des fonctions de résilience en rapport avec les différentes architectures qui vont se développer, en tenant compte notamment des nouveaux niveaux de stockage que nous évoquions.

Il y a clairement un gros effort à faire dans les années qui viennent pour définir ces API et pour que tous les intervenants concernés se mettent d’accord. Les développeurs applicatifs devront pouvoir utiliser ces API pour exprimer la sémantique de leurs codes et travailler sans avoir à tenir compte des modèles fins des machines. Si ces API tardent à apparaître, la communauté risque de perdre du temps, chacun allant dans sa propre direction.

Avec l’intégration massive des unités de calcul (CPU, GPU, APU) en perspective, considérez-vous la programmabilité comme un défi technique majeur ?

Il est certain que concevoir des applications fortement parallèles est un exercice intrinsèquement complexe. Le défi, de mon point de vue, est d’arriver à programmer en permettant l’expression de ce parallélisme massif. Pour faire le lien avec la question précédente, si on dispose d’API bien faites, on n’est plus obligé de se préoccuper de savoir si c’est un CPU ou un GPU qui calcule. Le runtime doit pouvoir aider et prendre les décisions en fonction des données et des ressources qui seront utilisées, adapter l’exécution de l’application à l’environnement matériel.

Pensez-vous, comme beaucoup d’observateurs, que l’efficacité énergétique soit l’obstacle majeur sur la route de l’Exascale ?

A l’évidence, l’efficacité énergétique est un enjeu majeur. Les roadmaps processeurs ne permettent pas aujourd’hui d’envisager l’exascale à 20 MW en 2020. Sur la simple puissance de calcul, on est encore très en deçà de ce qu’on cherche à obtenir. On doit également prendre en compte les mouvements de données, qui méritent eux aussi beaucoup d’optimisations pour que les solutions proposées aux utilisateurs fonctionnent dans des enveloppes énergétiques raisonnables.

Cela étant, il faut comprendre qu’avec 1018 opérations par seconde sur des processeurs cadencés à quelques GHz, on atteint quasiment le milliard d’opérations en parallèle. Il va nous falloir des méthodes de résolution qui facilitent les calculs en simultané avec le moins de synchronisations possible. Cette maîtrise du parallélisme est sans doute un défi aussi important que celui de l’efficacité énergétique.

Pour conclure, quelles grandes ruptures technologiques voyez-vous se profiler d’ici 2020 ?

Je pencherais plutôt pour des évolutions fortes que pour de véritables ruptures. J’ai quelques doutes, personnellement, sur l’émergence prochaine de superordinateurs quantiques, de machines au graphène, d’architectures neuro-mimétiques pour le calcul, etc. Nous sommes encore aujourd’hui sur des technologies logicielles et matérielles – notamment le CMOS – qui permettent de continuer à avancer. Or, les alternatives que nous venons de citer sont loin d’avoir le même degré de maturité. Sans doute arriveront-elles, mais pas en 2020…