A l’ordre du jour :
• Dans les coulisses d’Oak Ridge
• Ce qu’implique le passage aux GPUs
• Une roadmap pour les successeurs de Titan
• Les bénéfices de la compétition avec la Chine…

Propos recueillis par Stéphane Bihan

Monsieur Wells, pouvez-vous nous présenter brièvement le laboratoire d’Oak Ridge et nous en dire plus sur vos fonctions au sein de cette organisation ?

Oak Ridge National Laboratory est le plus grand laboratoire scientifique du Département de l’Energie américain (DoE), avec des capacités très étendues en sciences des matériaux et de l’ingénierie. Notre division informatique et calcul numérique est l’une des cinq divisions du laboratoire, qui comptent chacune environ 600 personnes. ORNL totalise ainsi 3300 employés avec le personnel de support.

Le Laboratoire a hérité du projet Manhattan durant la seconde guerre mondiale. Depuis, la mission qui lui est confiée se situe au croisement des sciences et technologies de la matière et du nucléaire. Au cours des quinze dernières années, nos capacités en sciences et technologies neutroniques et informatiques se sont considérablement accrues. La mission de l’OLCF (Oak Ridge Leadership Computing Facility), à laquelle j’appartiens, est de fournir et d’opérer une installation de calcul qui soit la plus puissante possible, à des fins de recherche pour l’industrie américaine, les universités, notre laboratoire et la majorité des agences fédérales. Outre nos propres installations, nous hébergeons également celles que finance la National Science Foundation et que gère l’université du Tennessee. Nous avons également deux départements de recherche : la Computer Science and Mathematics Division et la Computer Science and Engineering Division.

L’OLCF dispose aujourd’hui de Titan, le deuxième calculateur le plus puissant au monde selon la liste Top500. Nous en assurons l’exploitation pour le compte de nos utilisateurs, l’accès a ses capacités de calcul étant accordé après sélection dans le cadre de programmes d’appel à projets.

En tant que Director of Science, mon rôle est de permettre à notre communauté d’utilisateurs de parvenir à des résultats scientifiques d’excellence. Concrètement, cela consiste à gérer les programmes d’allocation et d’utilisation des ressources, à évaluer les besoins réels des utilisateurs pour la programmation des prochains équipements et à diffuser les résultats de nos recherches le plus largement possible.

Titan est en production depuis début 2013. Comment s’est déroulé le processus d’installation d’une telle machine, depuis les premières concertations jusqu’à la livraison aux utilisateurs ?

En janvier 2009, Ray Orbach, alors en charge des investissements scientifiques du DoE, a signé un ordre de mission d’étude destiné à l’accroissement de notre système OLCF de 10 à 20 Pflops. Janvier 2009 a donc été le point de départ du projet OLCF-3 que vous connaissez sous le nom de Titan. L’approbation formelle de notre stratégie de sélection et d’acquisition, ainsi que l’enveloppe budgétaire, a eu lieu en décembre 2009. Nous avons proposé un ensemble de solutions techniques susceptibles de répondre à nos besoins, à partir duquel nous avons commencé à progresser vers notre objectif. Tout cela s’est déroulé dans un processus de gestion de projet très structuré alternant évaluations et décisions managériales. Et c’est en août 2010 que l’OLCF reçut le feu vert du DOE pour la commande du système sélectionné, un Cray XK7.

Avez-vous discuté avec d’autres constructeurs ?

L’orientation prise pour le marché OLCF-3 était une mise à niveau de la machine Jaguar [Ndlr : un Cray XT5] plutôt que l’acquisition d’un nouveau calculateur. Il s’agissait donc d’un marché à fournisseur unique.

Quel était le budget global pour la construction de cette machine ? Pouvez-vous nous indiquer aussi une estimation (et la répartition) de ses coûts de fonctionnement ?

Globalement, on est aux alentours d’une centaine de millions de dollars. Pour l’opérationnel, notre budget se répartit en trois charges principales. La première, c’est le coût de location. Nous n’achetons pas la machine, ce qui nous permet d’étaler les dépenses au travers d’un bail qui s’étale sur une période de 4 à 5 ans. C’est d’ailleurs la raison pour laquelle ce poste fait partie intégrante du budget de fonctionnement. Les deux autres charges sont les coûts d’énergie et les frais de personnels.

Quelle est la consommation électrique de Titan ?

Lorsque Titan exécute des applications de calcul intensif comme le benchmark Linpack, il consomme environ 8,2 MW, comme indiqué dans les métriques du Top500. En incluant le refroidissement, qui compte pour environ 20 % de la consommation électrique globale, nous arrivons à 10 MW pour cette seule machine. Mais nos installations peuvent supporter une charge de 25 MW, ce qui nous permet d’opérer également d’autres systèmes pétaflopiques : il y a notamment le calculateur Kraken que nous exploitons pour le compte de la National Science Foundation, une autre machine exploitée pour le compte de la NOAA (National Oceanic and Atmospheric Administration), et tous les autres serveurs, clusters et stations de travail du laboratoire.

Pourquoi avez-vous choisi une architecture hybride à base de GPU ? Faut-il y voir une quelconque influence de la part de NVIDIA ?

C’est en fait le résultat d’une enquête minutieuse auprès de nos utilisateurs. Grâce à elle, nous avons pu déterminer que l’exigence principale pour l’acquisition d’un nouveau système ou la mise à niveau de l’existant était la puissance de calcul brute, qui devait être augmentée dans le but de permettre des simulations plus exigeantes. C’est pourquoi, plutôt que d’ajouter plus de nœuds ou plus de cœurs, nous avons décidé d’accroître la puissance des nœuds. A la suite de discussions avec NVIDIA, nous avons été convaincus que les GPU pourraient satisfaire cette exigence pour la plupart de nos applications. Vous savez, à l’époque, notre communauté commençait à penser que, pour atteindre l’exascale, les nœuds devraient être plus hétérogènes. Nous pensions que l’hétérogène était ce à quoi le futur ressemblerait et donc, en tant que centre leader, nous avons décidé de sauter le pas.

Voyiez-vous un risque dans l’adoption des technologies GPU ?

Oui, le risque principal que nous avions identifié et que nous avons réussi à surmonter était que nos codes ne puisse pas s’exécuter sur cette machine, qu’ils ne puissent pas utiliser efficacement les GPU.

Porter un certain nombre de codes devait donc faire partie du processus d’évaluation, n’est-ce pas ?

Oui, dans le cadre du processus d’acquisition évoqué précédemment, la phase de préparation impliquait la définition et la validation d’une stratégie de portage des codes. Si cette stratégie n’avait été validée, nous n’aurions pas pu continuer le projet. Mais nous avons réussi en convaincant le comité de validation que notre stratégie pour amener les codes à utiliser la machine était la bonne.

Justement, quelles stratégies techniques ORNL a-t-il adopté pour amener les codes utilisateurs d’un parallélisme CPU à une accélération GPU ?

C’est une question importante. Comme on vient de le voir, très tôt dans le projet, nous avons eu à définir une stratégie de portage globale. Le point clé de cette stratégie a été la création d’un groupe de préparation des codes à l’accélération, le CAAR (Center for Accelerated Application Readiness). Une fois le CAAR constitué, nous nous sommes focalisés sur un certain nombre d’applications choisies en fonction de leur diversité et de leurs exigences techniques – exigences qui devaient être représentatives de la diversité des problèmes scientifiques que nous avons à traiter. Les codes sélectionnés incluaient notamment LAMMPS, un code de dynamique moléculaire développé à l’extérieur d’ORNL, S3D, un code de combustion, LSMS, un code de sciences de la matière développé ici, Denovo DM, un code d’analyse de la radiation des neutrons également développé ici pour les réacteurs nucléaires, et CAM-SE, un code communautaire de modélisation de l’atmosphère par éléments spectraux utilisé dans une application de climatologie plus importante.

Comment ce groupe a-t-il été structuré ?

Pour chacune des applications, nous avons constitué une équipe comprenant un responsable ORNL, un ingénieur Cray, un ingénieur NVIDIA et autant d’ingénieurs de développement que nécessaire. Lorsque nous avons eu besoin de compétences externes issues d’une autre université ou d’un autre laboratoire, nous les avons contractées. Une fois les équipes formées, le portage des codes de Jaguar à Titan a représenté en moyenne une à deux années-homme pour chacun. Je dois préciser que nous n’avons pas souhaité porter l’ensemble des codes utilisés à Oak Ridge car nombre d’entre eux sont des travaux communautaires comprenant des composants utilisés ailleurs pour résoudre des problèmes de natures très diverses. Nous avons plutôt essayé de sélectionner des codes qui nous paraissaient à la fois gérables pour ce projet et représentatifs au niveau scientifique. C’est un modus operandi déterminant dans ce type de projet : il faut essayer de se focaliser sur quelques applications pour réussir dans un temps et un budget finis. D’autant que les codes en question, en plus d’autres benchmarks plus traditionnels, faisaient partie de la suite de tests utilisée pour recetter la machine. Chemin faisant, nous avons d’ailleurs appris un certain nombre de choses, en particulier sur les restructurations de code, une dimension majeure pour le passage à une architecture basée sur les accélérateurs. Grosso modo, cette phase de restructuration compte pour environ 70 à 80 % de l’effort total. Attention, ces chiffres ne sont pas liés à l’utilisation d’un modèle de programmation propre aux GPUs. Ils auraient probablement été les mêmes avec des coprocesseurs Intel MIC. Dans tous les cas, il ne s’agit ni plus ni moins que de préparer les codes à un parallélisme hiérarchique.

En d’autres termes, vous avez préféré modifier les algorithmes plutôt que les modèles scientifiques ?

Exactement. Cette approche découle de l’architecture mémoire de Titan. Il nous a notamment fallu réordonner certaines structures de données – changer des tableaux de listes en listes de tableaux, par exemple – de façon à ce que, tout en bas de la hiérarchie mémoire, les données soient suffisamment bien organisées pour que l’accélération GPU donne le maximum de son potentiel. Ce travail requiert une combinaison d’expertises variée, notamment en science, en ingénierie numérique, en architecture des processeurs, etc. Nous l’avions déjà expérimenté pour Jaguar et, au final, à peu près tous les codes s’exécutaient deux fois plus vite. Travailler sur les codes, réfléchir à l’optimisation de leur exécution sur la machine cible est une bonne chose. Parfois, ces codes tournent en production depuis un certain temps sans que personne n’ait l’idée de les remettre en question… Dans la perspective de l’arrivée des prochaines générations de machines, ces restructurations de code sont essentielles. C’est pourquoi, que l’on utilise CUDA, OpenCL ou OpenACC pour programmer les accélérateurs, il faut s’y préparer.