Rendez-vous avec William JALBY,
Professeur à l’Université de Versailles – St-Quentin-en Yvelines
Chief Scientist à l’Intel Exascale Computing Research Lab

Propos recueillis par Frédéric MILLIOT

HPC Today : L’Exascale Computing Research Lab a été créé en 2010. Pourriez-vous nous présenter ses objectifs en quelques mots ?

William Jalby : Vous le savez, l’exascale représente un facteur 1000 par rapport à ce que l’on connaît aujourd’hui. Pour y parvenir, on ne pourra pas simplement extrapoler la technologie telle qu’on la connaît. Il va falloir que la communauté réalise de gros progrès au niveau applications, au niveau OS et au niveau architecture matérielle. C’est la mission de l’ECR que de contribuer à ce cahier des charges. Au laboratoire de Versailles, l’équipe travaille essentiellement sur deux grands axes : les applications et les outils.  Concernant les applications, il s’agit d’abord de les amener au bon degré de parallélisme. Le but n’est pas de développer de nouvelles versions from scratch mais d’affiner l’existant en collaborant le plus étroitement possible avec les utilisateurs finaux – eux seuls ayant une vision claire des objectifs à atteindre en matière de simulation numérique. L’idée, plus précisément, c’est de les aider à intégrer un certain nombre de contraintes déjà identifiées pour la machine exaflopique type : outre le degré de parallélisme déjà évoqué, citons par exemple l’optimisation des accès aux données. De là découle notre deuxième axe de recherches, à savoir l’ensemble des outils permettant la mise à l’échelle. Si vous regardez bien, les machines pétaflopiques d’aujourd’hui sont assez décevantes : la majorité des codes ne fonctionne qu’à 5 % de la puissance peak. Comme une Porsche donnée pour 250 km/h qui ne roulerait qu’à 12,5 km/h, et cela sans bénéfice sur la consommation. Alors, quels sont ces “outils” dont on parle ? Il y a d’abord le runtime, car du runtime dépend la gestion des ressources. On cherche également à mieux comprendre comment s’établit la performance au niveau du nœud : optimisation des échanges de données, points bloquants… Les architectures de processeurs s’étant sérieusement complexifiées au cours des années, comprendre ces points de blocage s’avère difficile. Enfin, les aspects énergétiques nous occupent aussi beaucoup, et notamment la question de savoir comment telle ou telle application utilise les fonctionnalités matérielles sous-jacentes. Concrètement, on cherche à faire en sorte que tous les Joules dépensés le soient de façon utile, par exemple en éteignant tel ou tel sous-système hard lorsqu’il n’est pas utilisé. Jusqu’à présent, on a vécu sans trop se préoccuper de l’efficacité énergétique. Pour l’exascale, ce gâchis est terminé !

Quel est, dans ce contexte, l’avantage de fonctionner en partenariat public/privé ?

Clairement, les industriels jouent un rôle moteur dans l’avancement des technologies sur lesquelles et avec lesquelles nous travaillons. Ce sont eux, en dernier ressort, qui produisent les briques de base de nos systèmes. De ce fait, avoir une bonne connaissance des problèmes techniques et des potentialités réelles de ces briques nécessite une véritable collaboration, de véritables échanges. Je peux dessiner une machine idéale, aller voir Intel et lui demander de me la fabriquer… mais je doute que le projet aboutisse, ne serait-ce qu’à cause des contraintes d’industrialisation. C’est là un point fondamental, qui fait tout l’intérêt de l’ECR. D’où, également, la présence de nombreux industriels dans les partenariats que nous développons avec les utilisateurs finaux – à commencer par Total par exemple. Cette tendance globale s’affirme d’ailleurs dans de nombreux secteurs de la recherche. On doit aussi envisager les problèmes dans leurs dimensions sociétales et, pour cela, l’interaction avec les industriels est indispensable.

Combien de personnes travaillent à vos côtés ?

L’équipe compte une trentaine de personnes, dont trois ingénieurs Intel et deux ingénieurs CEA-DAM. Si je les mentionne, ce n’est pas par hasard. Classiquement, dans un labo de recherche, on compte une moitié de maîtres de conférence et de chercheurs à plein temps, et une seconde moitié de doctorants. Chez nous, l’équipe se divise en trois tiers : un tiers de doctorants, un tiers de post-doctorants, maîtres de conférence et professeurs, et un troisième tiers d’ingénieurs. Pourquoi ? Parce que notre mission de départ est de créer des outils Open source diffusables. Or, sur une durée de thèse de 3 ans, on ne peut pas demander au thésard d’avoir des idées, d’être le roi du logiciel et de savoir écrire parfaitement. Donc, typiquement, le doctorant va développer et valider une idée sur quelques exemples, montrer que “ça marche”. Ensuite, pour le passage à l’échelle, il faudra réécrire l’application et c’est là que les ingénieurs entrent en piste – suivant le principe que tout bon logiciel est un logiciel qui a été écrit trois fois (je ne plaisante qu’à moitié)…

L’ECR de Versailles est un des quatre laboratoires crées par Intel en Europe dans le but de paver la voie de l’exascale. Quel est le rôle des trois autres ?

Les enjeux de l’exascale étant très très larges, il nous faut travailler en synergie. A Jülich, an Allemagne, on est plutôt sur la réalisation d’un gros système basé sur l’architecture DEEP (Dynamic Exascale Entry Platform). A Louvain, on travaille sur des aspects plus fondamentaux, notamment au niveau algorithmique, avec une approche intéressante car verticale. Globalement, il s’agit de prendre une application et de l’examiner sous toutes ses coutures, des calculs de base à l’architecture matérielle nécessaire pour la faire tourner, afin d’identifier à chaque étage la meilleure approche dans une optique exascale. En ce sens, et compte tenu de l’éventail des compétences requises, nos amis Belges sont un peu plus “recherche” (leur laboratoire s’appelle d’ailleurs “ExaScience”, tandis que celui de Jülich s’appelle “ExaCluster” et le nôtre “Exascale Computing Research”). Enfin, un quatrième laboratoire, créé l’année dernière en collaboration avec le Barcelona Supercomputing Center (BSC), a pris en charge notamment la question de la mise à l’échelle des runtimes et les outils d’optimisation et de prédiction adaptés aux environnements HPC à base x86 / MIC.

Pourquoi une implantation en Europe, plutôt qu’aux Etats-Unis ou dans les pays émergents à haut niveau de compétences informatiques ? 

Parce que l’Europe a une tradition forte dans le domaine des applications. Regardez sur le site ETP4HPC : l’Europe représente environ la moitié du marché HPC. Notre vieux continent est par ailleurs source de beaucoup d’innovations logicielles. Par exemple, sur les questions de combustion, la France est leader. Voilà, c’est comme ça. Plus globalement, les enjeux de souveraineté sont tels que l’Europe, de par sa nature multinationale, est porteuse d’initiatives et de budgets. Le contexte européen était donc tout à fait favorable, d’autant que des compétences HPC de très haut niveau sont présentes dans quasiment tous les domaines.

En tant que Chief Technologist, qualifieriez-vous l’ECR de laboratoire de technologies ou de laboratoire d’idées ?

De laboratoire d’idées prenant en compte des contraintes réelles. Par exemple, les processeurs dont on dispose sont ce qu’ils sont. Ils ont leur qualités et leurs défauts, et on doit faire avec. On ne peut pas, comme je disais précédemment, imaginer une architecture ou un langage idéal en oubliant l’existant. La durée de vie d’une application HPC, c’est 15 – 20 ans. Faire un trait sur le code legacy n’aurait aucun sens, ni sur un plan technique, ni sur un plan économique. C’est d’ailleurs la raison pour laquelle la route vers l’exascale sera faite d’évolutions successives, plutôt que de révolutions auxquelles je ne crois pas.

Un laboratoire d’idées appliquées, donc ?

Tout à fait. Nos idées doivent s’intégrer à l’évolution des processus industriels qui nous mèneront à l’exascale. C’est cette multiplicité de contraintes qui rend nos travaux si complexes. Dans l’absolu, croyez-moi, on a beaucoup d’idées géniales ; le problème, c’est que peu sont réellement transformables concrètement.

A votre avis, quels sont les principaux obstacles technologiques qui, justement, nous séparent de l’exascale ?

J’en vois plusieurs, à commencer par le très fort degré de parallélisme. Quand on n’est plus sur le papier, on s’aperçoit qu’il ne suffit pas d’étaler une application sur un million de processeurs pour résoudre le problème. D’abord, celles qui tiendraient le choc ne sont pas légion. Mais surtout, la question se pose en termes de niveaux de parallélisme. Prenez l’exemple de la recherche sismique. On a d’un côté un certain niveau de maillage, qui n’est pas censé augmenter significativement parce que le nombre de capteurs restera limité. De l’autre côté, il y a les points d’analyse. Là, on peut imaginer faire tourner 10 000 fois le même code sur des données différentes. C’est la classique opposition capacity / capability computing. Dans ces conditions, comment gérer ce degré de parallélisme ? Faut-il reconfigurer la machine en 1000 x 1000 cœurs, 100 x 10 000 cœurs, ou encore 10 000 x 100 cœurs ?

Ensuite, bien sûr, les problèmes énergétiques sont réels. Si je dispose d’un budget énergie de X Joules. je dois comprendre parfaitement l’application pour utiliser chaque Joule au maximum. Ce problème du ratio performance / Watt est aujourd’hui vraiment essentiel, c’est pour lui qu’on se bat tous les jours. Et quand on cherche à analyser finement l’application cible, on se rend compte qu’elle est en général tout sauf uniforme. A certaines étapes, elle va tirer sur la mémoire, à d’autres elle va ne pas utiliser tel sous-système, etc.  D’où la nécessité d’une part d’optimiser les architectures système avec le maximum de granularité, mais aussi d’autre part de caractériser finement les applications. Imaginons que vous dirigiez un portefeuille composé d’une centaine d’applications. Pouvoir les découper en portions – ou “codelets” – est une approche très intéressante. Sachant qu’un grand nombre de ces codelets va se comporter de la même façon par rapport à vos objectifs applicatifs, vous allez pouvoir les regrouper. Et donc cesser de raisonner application par application mais codelet par codelet. Ce qui vous autorise de bien meilleurs optimisations, plus rentables en termes d’efforts d’affinage.

Enfin, les obstacles purement techniques me semblent globalement en passe d’être levés. Prenez par exemple les interconnexions. L’avènement prochain de l’optique est synonyme de très hautes performances pour un coût raisonnable. Quant à la question cruciale de la fiabilité, je ne me fais pas beaucoup de souci non plus. L’approche résilience est tout à fait envisageable dans la mesure où le HPC utilise des composants de grande diffusion. Des processus de fallback, basés sur des composants présentant eux-mêmes une bonne fiabilité, devraient suffire. D’autant que, d’expérience, c’est en général moins le matériel que le logiciel qui “plante” ! 

Et vous arrivez à caractériser la fiabilité ?

Le MTBF [Mean time between failures – Ndlr] nous donne des indications statiques mais la vraie difficulté est de faire face aux dysfonctionnements. Pour cela, le runtime doit surveiller l’ensemble des processus logiciels et matériels. Pour les pannes soudaines, par nature imprédictibles, des processus d’adaptation peuvent être mis en place sous certaines conditions. En revanche, dans beaucoup d’autres cas, on peut voir un problème se former puis se confirmer (mémoire disponible qui diminue, temps typique de calcul qui augmente, etc.). Ces choses-là doivent être gérées par l’application.   

La sortie de Xeon Phi inscrit Intel dans une stratégie durablement many-cores. La stratégie GPU multicores semble également donner d’excellents résultats en pratique, comme le souligne l’état actuel du Top500. Comment voyez-vous, à terme, évoluer cet antagonisme ? 

Pour moi, le problème du GPU computing est qu’il implique un modèle de programmation dédié. Je dis cela sans partialité envers Intel. Ce que j’observe, personnellement, c’est que si les académiques peuvent être enclins à réécrire leurs applications, les ISV, de leur côté, me semblent beaucoup plus tièdes… Ensuite, et je m’exprime toujours en mon nom personnel, je réfute un peu le terme “accélérateur GPU”. Je fais également partie d’un second laboratoire HPC – cette fois indépendant d’Intel – et dans ma pratique, je dois dire que je suis assez content quand ces accélérateurs ne freinent pas. Maintenant, je ne dirai pas que Phi est parfait. Comme souvent avec les technologies de ce type, il faudra probablement attendre la troisième itération [Phi dans sa version Knights Corner actuelle étant la deuxième – Ndlr] pour que l’accélération soit pleinement exploitable, avec par exemple une technologie de mémoire unifiée. Reste que Phi garde le bon vieux programming model x86 qu’on connaît tous et ça, pour moi, c’est un atout vraiment majeur.

D’un autre côté, l’approche d’AMD et NVIDIA qui consiste à intégrer en un même “dye” CPU et accélérateur GPU paraît prometteuse en matière d’efficacité énergétique, de bande passante et de coûts d’intégration et de production. Qu’en pensez-vous ?

C’est effectivement une excellente idée. Intel suivra probablement la même voie. Sachant que le HPC restera une niche, ces composants hybrides, ou intégrés, devront pouvoir être réutilisés ailleurs pour que leur fabrication soit rentable. Mais tout est en train de se mettre en place. La technologie se développant en général par le bas, on peut penser que cette intégration se fera d’abord pour répondre aux besoins de calcul grandissants des “petits” terminaux. Vu l’évolution du marché des smartphones et des tablettes, on y est, quasiment.

Justement, à ce propos, voyez-vous l’arrivée de serveurs ATOM comme annonçant un nouveau type d’infrastructure, où les cœurs seraient des commodités peu coûteuses et donc plus facilement intégrables à très grande échelle ?

Pour moi, Atom est un processeur extrêmement intéressant du fait de son efficacité énergétique et de sa fiabilité. On a d’ailleurs une machine Atom ici. Elle est assurément moins rapide qu’un Sandy Bridge, mais pas moins efficace. Il fut un temps où l’on pouvait se permettre d’ajouter un  million de transistors sur un processeur haut de gamme pour gagner 4 % de rapidité, mais cette époque est révolue. A ce titre, Atom est un excellent candidat pour l’intégration en masse.

Restons un instant sur ce sujet. Quels avantages l’architecture x86 garde-t-elle par rapport à ARM, par exemple ?

Je vais être direct : l’architecture x86 souffre d’un jeu d’instructions vieillot, de taille variable et devenu trop complexe du fait de la compatibilité descendante. En revanche, elle convient à toutes les générations d’applications. ARM, de son côté, est parti 10 ans plus tard, sur une base un peu plus “clean“. Faire un désassembleur ARM – pour mettre un binaire en Open source, par exemple – est donc infiniment plus simple que de faire un désassembleur x86. Ensuite, la différence, c’est qu’en allant chez Intel, vous achetez un produit. En allant chez ARM, vous achetez des plans. Ce n’est pas la même chose, même si ça a de bons côtés : on peut avoir des processeurs clairement dédiés à certains usages, avec moins de diviseurs, plus d’additionneurs… sauf qu’ensuite, il faut trouver un fondeur.

Faisons un peu de divination. Quel sera, selon-vous, le profil-type du premier cluster exaflopique d’un point de vue technique ?

Pour moi, ce premier cluster exaflopique sera inutilisable.  Il s’agira probablement d’un entassement extrême de technologies mal dimensionnées. On réalisera une performance et on démontera le tout aussi vite. Il y a d’ailleurs des chances que ce soit la Chine qui grimpe ce premier Everest, pour des raisons principalement politiques. Mais ce qui compte réellement, c’est le premier cluster en exploitation. A mon avis, il aura des accélérateurs intégrés. Ou plutôt des processeurs vectoriels en grande quantité, sans doute issus d’une convergence avec les CPU haut de gamme actuels. Par ailleurs, cette machine sera probablement hiérarchique, avec une architecture en ilots, pour que, selon l’application, on puisse mobiliser tels ou tels ilots conjointement. Avec certainement plus d’un million de cœurs, mais regroupés en peut-être une centaine de ces ilots.

La communauté pronostique l’avènement de l’exascale pour 2020. Les plus optimistes évoquent même 2018. A vos yeux, c’est réaliste ?

Probablement. On devrait y arriver. Et comme je vous l’ai dit, je parie que ce seront nos amis chinois qui seront les premiers à réclamer la palme. Vu le pragmatisme qui les caractérise, ce sera peut-être avec leurs propres initiatives en matière de processeurs… On arrivera d’abord à l’objectif avec un coût dément, une alimentation électrique qui atteindra peut-être 40 MW, mais on y arrivera à cet horizon 2018-2020. C’est le passage à la normalisation, pour un coût d’exploitation rentable et une consommation de croisière soutenable, qui reste la grande inconnue.