Flash informatique 2010 - no 10 - HPC

10 http://dit.epfl.ch

SPÉCIAL CALCUL À HAUTE PERFORMANCE

p/a EPFL - Domaine IT - CP 121 - CH 1015 Lausanne 15 - tél. +41 21 69 322 11

Actualités

Actualités CADMOS V. Keller

2

Master CSE V. Keller & S. Deparis

16

HPC: l'énergivore A. Boisseau

38

Conférence GPU F. Lapique

40

Conférence SC10 J.-C. Berney

42

Analyse La loi de Moore Ch. Piguet

5

Mot-croisé: Modèle F. Jaunin, M. Picasso & E. Rosales

6

in-situ visualization J. M. Favre

8

Akantu N. Richart, G. Anciaux & J.-F. Molinari

11

Simulations au LASTRO Y. Revaz

13

InfiniBand D. Cervini

18

HPC@GreenIT V. Keller & R. Gruber

26

On-chip cooling using microevaporators J. Marcinichen, J. Olivier & J. Thome

29

Thermal-Aware Design for 3D Multi-Processors D. Atienza

34

À votre service L’expérience SuperB V. Rezzonico

21

Grille de calcul nationale P. Jermini

24

Calculons au DIT ! M. Thiemard

27

No Délai de rédaction Parution 06.01.11

25.01.11

2

03.02.11

22.02.11

3

10.03.11

29.03.11

tout public public averti expert

De FLOPS et de watts Vittoria.Rezzonico@epfl.ch, EPFL - SB-IT, spécialiste HPC et responsable de la salle serveur de la Faculté des Sciences de base

Le calcul scientifique est un outil fondamental pour la recherche. Pour la troisième année, vous allez mieux connaître quels résultats scientifiques existent grâce aux supercalculateurs de l'EPFL. Vous y trouverez aussi un rappel et les nouveautés concernant les serveurs centraux.

Mais les supercalcultateurs consomment de l'énergie et nécessitent du refroidissement.

Qu'il s'agisse de concevoir un supercalculateur avec une efficacité énergétique jamais vue, d'évacuer la chaleur proche des composants les plus critiques ou bien d'étudier des façons de profiter de la 3ème dimension dans la création des chips, les laboratoires de l'EPFL se penchent déjà sur des problèmes énergétiques. C'est à cela qu'on doit les pages 26 à 39 de ce numéro.

Vers une nouvelle revue consacrée au calcul scientifique ?

Après trois numéros Spécial HPC du Flash Informatique bien remplis, en 2008, 2009 et 2010, il est temps que le Spécial HPC se détache du FI. Les raisons qui ont porté à

Prochaines parutions 1

21.12.2010

cette décision sont multiples, on peut par exemple en citer deux: z la différence entre le public standard du Flash Informatique et celui du Spécial HPC; z trop de FI spéciaux en 2010 (trois).

Certains d'entre vous se souviennent du EPFL SuperComputing Review [go.epfl.ch/scr], cette nouvelle revue sera un peu comme son come-back.

Voici une brève description de la nouvelle publication: Contenus et public cible de la revue La revue sera comme le Flash Informatique Spécial HPC, plus vulgarisé que le Supercomputing Review mais avec un nouveau design.

Comité de rédaction Vittoria Rezzonico et Michela Thiémard seront épaulées par un comité de rédaction composé essentiellement par des acteurs du HPC à l'EPFL. Le nom de la revue reste encore à inventer.

C'est pour cela que cet édito se termine par un concours. n

Concours

Proposez un nom pour la future revue HPC de l'EPFL et gagnez une radio Logitech Squeezebox™.

Envoyez votre proposition avant le 25 janvier 2011 avec une brève explication de votre choix à fi@epfl.ch, sujet: concours HPC. Ce concours est ouvert à tous. Le résultat sera publié dans le FI2/2011.

Actualités

Lorsque les étoiles s’estompent, CADMOS brille plus fort Vincent.Keller@epfl.ch, EPFL – CADMOS,

Do you know CADMOS [1]? Acronym for Center for Advanced Modeling Science, the CADMOS project has been launched end of 2009 as a collaboration between EPFL and the Universities of Lausanne and Geneva. CADMOS is the flagship of the computational science in the Lake Geneva region. The goal of this small paper is to give an overview of the different accepted projects within CADMOS. These projects will be viewed alongside the 5 Grand Challenges of EPFL described in 1993 in a paper written

by Marie-Christine Sawley.

CADMOS [1] vous connaissez ? Acronyme pour Center for Advanced Modeling Science, le projet CADMOS a été lancé fin 2009 comme collaboration entre l'EPFL et les universités de Lausanne et de Genève comme moteur régional du calcul scientifique.

Le but de ce bref article est de parcourir, de façon superficielle, les différents projets déposés et acceptés depuis mars 2010 dans le cadre du projet CADMOS et en les mettant en perspective avec un article de 1993 intitulé Les 5 Grand Challenges de l'EPFL écrit par Marie-Christine Sawley.

Petit retour en arrière, il y a 17 ans à l’EPFL...

En novembre 1993, dans le premier numéro hors série du Flash Informatique et sous la plume de Marie-Christine Sawley [2], cinq applications pilotes ou domaines locomotives (c’était le terme employé à l’époque) étaient identifiés. Ces applications devaient permettre d’aider à la diffusion de l’expertise de ses utilisateurs en matière de simulation numérique (fameux troisième pilier de la recherche scientifique). Les applications Grand Challenges étaient:

Impressum Les articles ne reflètent que l’opinion de leurs auteurs. Toute reproduction, même partielle, n’est autorisée qu’avec l’accord de la rédaction et des auteurs.

Abonnement à la version électronique du FI en envoyant un courrier à: fi-subscribe@listes.epfl.ch

flash informatique

1 la compréhension des régimes turbulents en 3D sur des géométries complexes dans la dynamique des fluides computationnelle (CFD), 2 la physique des plasmas, 3 la physique de la matière condensée et la dynamique moléculaire, 4 le traitement des signaux.

Ces quatre Grand Challenges permettaient de démontrer le besoin d’entrer de plain-pied dans l’ère du massivement parallèle avec l’achat d’un CRAY-T3D (une machine avec 128 processeurs Alpha – étendu à 256 une année plus tard – dont on peut toujours aujourd’hui admirer la carcasse dans les couloirs du CM) en remplacement du vieillissant CRAY-2 (lui aussi en exposition aux côtés du T3D). Le cinquième Grand Challenge identifié était celui de la révolution MPI/PVM &, soit l’arrêt – provisoire – du pur séquentiel/vectoriel dans le développement des codes scientifiques et l’arrivée du message passing.

La conclusion de l’article, mise en perspective aux objectifs de CADMOS, est particulièrement pertinente et incroyablement d’actualité. Elle consistait en cinq objectifs que je vous livre in extenso: 1 développer ou adapter en collaboration avec CRAY des applications existantes sur l’architecture T3D, 2 développer les échanges avec les autres centres PATP (les centres de collaboration avec Cray) où l’EPFL peut jouer un rôle actif, 3 identifier, stimuler et intégrer d’autres groupes faisant de la simulation et nécessitant d’importants moyens de calcul ainsi que donner de l’impulsion à certaines disciplines, 4 rechercher des synergies avec les industriels potentiellement intéressés à ces techniques et 5 former des ingénieurs en techniques de calcul massivement parallèle (3ème cycle).

L’auteure précise que ces applications Grand Challenges ne pourront être résolues sans recourir à des machines avec des puissances de l’ordre de 100 à 1000 fois plus grande que ce qui existait en 1992, à savoir des machines autorisant des performances de l’ordre du TF &. Cette puissance a été atteinte en 1997.

Rédacteur en chef: Vittoria Rezzonico fi@epfl.ch

Mise en page & graphisme: Appoline Raposo de Barbosa Comité de rédaction: Aristide Boisseau, Paulo de Jesus, Jacqueline Dousson, Patrice Fumasoli, Jean-Damien Humair, Laurent

Kling, Julia Paolini, François Roulet, Christophe Salzmann, Predrag Vicei´c & Jacques Virchaux Impression: Atelier de Reprographie EPFL Tirage: 4000 exemplaires Adresse Web: dit.epfl.ch/FI-spip Adresse: Domaine IT EPFL CP 121, CH-1015 Lausanne 15 Téléphone: +4121 69 32246 & 32247

Lorsque les étoiles s’estompent, CADMOS brille plus fort Quelles sont les applications Grand Challenges aujourd’hui ?

2010, sur l’arc lémanique

nal Theory) et la TDDFT (Time-Dependent DFT). Ces nouvelles techniques sont appliquées à des systèmes biologiques et chimiques tels que: les voies de signalisation dans les récepteurs couplés aux protéines G, les processus chimiques obtenus lors de thérapie de tumeurs profondes par faisceaux d’ions largement chargés (hadronthérapie), les transferts d’électrons à longue distance dans les protéines, l’optimisation de propriétés spectrales de colorants inorganiques utilisés dans les cellules solaires Grätzel. Les applications de chimie computationnelle, gourmandes en temps calcul et en communications inter-processus consomment environ un quart (25.4 %) de la puissance totale du BlueGene/P de CADMOS.

Physique des plasmas

utilisation du BlueGene/P de CADMOS - de mars 2010 à septembre 2010

Aujourd’hui en 2010, le parc informatique prévu pour le calcul à haute performance au sein de l’EPFL est essentiellement formé des trois clusters centraux Callisto, Vega et Antares et d’autres clusters départementaux (comme la machine de STI Pleiades). Ces étoiles du calcul parallèle permettent à la majorité des applications de l’école de trouver processeur à leurs boucles. Il y a cependant des applications qui demandent une puissance de calcul encore supérieure. C’est là que CADMOS entre en piste. Ces applications sont en quelque sorte les Grand Challenges de l’arc lémanique en 2010. Quelles sont-elles ? Ont-elles beaucoup varié en 17 ans ? Y a-t-il des nouveaux venus ?

Simulations numériques dans les sciences du vivant C’est le nouvel arrivant. Au-delà de toute considération philosophique ou morale, un organisme vivant est d’une complexité colossale et ce n’est pas après-demain que l’être humain sera capable de simuler un organisme entier, même simple, sur un support de silicone. J’en prends le pari avec celui qui écrira un article sur les Grands Challenges de l’EPFL en 2027. Parmi les grands projets CADMOS dans les sciences du vivant, on en trouve plusieurs types: d’un côté ceux qui se rapprochent de la dynamique des fluides avec des simulations du système cardiovasculaire [3], du flux sanguin dans les anévrismes cérébraux en passant par des simulations des échanges chimico-physiques dans les cellules, et de l’autre le grand projet BlueBrain [4] qui vise à comprendre les fonctions du système nerveux central et ses dysfonctionnements par ingénierie inverse. Durant le premier semestre 2010, les simulations numériques dans les sciences du vivant ont représenté 51.6 % de l’utilisation totale du BlueGene/P.

Chimie numérique C’est le second plus gros consommateur. Les applications de chimie computationnelle utilisent la célèbre méthode de CarParrinello dont les 25 ans ont été fêtés en 2010. Le laboratoire LCBC [5] développe une extension hybride entre la mécanique quantique (QM) et classique (MM) ainsi que des simulations de dynamique moléculaire (MD) basées sur la DFT (Density Functio-

La fusion thermonucléaire contrôlée pour la production d’énergie primaire n’est pas encore d’actualité, mais un grand pas a été fait dans la bonne direction avec le projet collaboratif mondial de réacteur expérimental ITER (International Thermonuclear Experimental Reactor) actuellement en construction à Cadarache dans le sud de la France [6]. À travers le CRPP, l’EPFL est depuis longtemps l’un des grands acteurs sur le plan mondial de la fusion.

Le tokamak à géométrie variable (TCV) – de loin la plus grande expérience du campus [7] – permet de tester les formes du plasma ainsi que les aspects liés à son chauffage (plus de 100 millions de degrés atteints grâce aux sources hyperfréquence gyrotrons). Les expériences pratiquées sur le TCV ne sauraient être complètes sans la simulation numérique, notamment dans la compréhension des turbulences dans le transport de chaleur et des particules dans un plasma fortement magnétisé. Ces projets majeurs sont menés notamment sur le BlueGene/P de CADMOS. Ils représentent à eux seuls 12.1 % de l’utilisation totale.

Géophysique Les méthodes de Boltzmann sur réseau LBM (Lattice Boltzmann Methods) sont des méthodes numériques prometteuses, simples à implémenter (le réseau est trivial en regard de celui des méthodes classiques d’éléments finis) et relativement novatrices. L’Université de Genève en est l’un des fers de lance mondiaux. L’idée du projet GeoLB de l’UNIGE pour CADMOS est d’appliquer la théorie de la dynamique des fluides computationnelle à la géophysique.

Au lieu de résoudre les équations de Navier-Stokes, on utilise l’approche de Boltzmann en simulant le fluide comme un ensemble de particules fictives que l’on propage et collisionne. GeoLB s’intéresse à l’établissement de la physique qui gouverne l’arrivée d’un gaz porteur injecté à la base d’un milieu non poreux initialement saturé d’un liquide. Si le taux d’injection du gaz est suffisamment élevé, il se forme des chemins préférentiels dans le liquide. Cette physique pourra directement être appliquée à la compréhension des phénomènes volcanologiques. Le projet GeoLB consomme environ 7 % des ressources de CADMOS.

Dynamique des fluides computationnelle (CFD) Le domaine de recherche de la dynamique des fluides computationnelle (CFD) est l’un des pères fondateurs du calcul à haute per-

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

3

Lorsque les étoiles s’estompent, CADMOS brille plus fort formance et des simulations numériques. Il est d’ailleurs présent dans plusieurs projets cités plus haut. Aujourd’hui et malgré le long chemin déjà parcouru, il reste un vaste champ de recherche et de la place pour des projets de haut niveau. Un seul projet, représentant 2.3 % de l’utilisation globale du BG/P de CADMOS est encore de la CFD. Le projet LESPRDHC (Large Eddy Simulation of Particle Removal inside a Differentially Heated Cavity) s’intéresse au rejet de matériaux fissiles dans l’atmosphère en cas d’accident nucléaire majeur. La dynamique des particules est simulée dans une cavité cubique à haut niveau de turbulence au moyen d’une simulation à grande échelle (Large Eddy Simulation – LES).

L’objectif est d’avoir une compréhension fondamentale de la physique impliquée dans les scénarios d’un tel accident. Ensuite, les résultats seront utilisés pour dériver des modèles plus simples pour pouvoir analyser de façon plus précise les risques dans la sécurité nucléaire. Même avec les ordinateurs les plus puissants du monde, il n’est pas possible de faire une simulation complète du confinement.

Physique de la matière condensée Dernier domaine traité par CADMOS et qui représente 1.6% de l’utilisation du BG/P, la physique de la matière condensée. L’étude effectuée par la chaire de simulation à l’échelle atomique [8] sur le BlueGene/P s’inscrit dans la recherche de solutions pour la période post-silicone dans l’électronique à échelle nano. Deux matériaux sont étudiés: le Germanium (Ge) et l’arséniure de Gallium (GaAs) ou l’Indium arséniure de Gallium (InGaAs). Le problème de cette technologie est qu’elle produit un nombre important d’états défectueux. Le projet se propose donc d’identifier la nature et l’origine de ces états défectueux par simulation numérique basée sur la dynamique moléculaire ab initio.

On le voit donc, des cinq Grands Challenges de 1993, tous le sont encore, mais on compte un nouvel arrivant: les sciences du vivant. Le fameux cinquième challenge, capacité des chercheurs à dompter du massivement parallèle existe toujours, mais le terme massivement a été requalifié. Les 128 processus parallèles de 1993 se sont transformés en plusieurs dizaines de milliers (plusieurs millions dans le futur) de processus parallèles et concurrents en 2010 ; la problématique existe toujours.

GLOSSAIRE

&

Modèle par échange de messages: modèle de communication entre processus. Chaque processus communique avec un ou plusieurs autres processus par messages. Les processus peuvent s'exécuter sur des machines différentes reliées par un réseau. Un message contient généralement un identifiant du processus émetteur et celui du recepteur ainsi que les données à transmettre.

4 flash informatique

Effets de bord et futur Du côté de l’enseignement, un master en sciences computationnelles a été mis en place. Il regroupe des cours aussi divers que variés provenant de plusieurs facultés. Ce master est le premier pas dans la réalisation du vœu de 1993: former des ingénieurs en sciences computationnelles prêts à relever les défis posés par le calcul scientifique; un défi où il s’agira de faire cohabiter plusieurs millions de threads en parallèle pour résoudre un problème, trouver des nouveaux algorithmes et méthodes numériques, maîtriser des systèmes de fichiers parallèles, utiliser des tailles de mémoire considérables. Les étudiants décorés d’un bachelor en sciences de base ou en ingénierie et intéressés par les défis posés par la simulation numérique et par l’informatique appliquée sont vivement encouragés à suivre le cursus Master in Computational Science and Engineering [9].

Il est à noter enfin que n’importe quel laboratoire de l’EPFL, de l’UNIL et de l’UNIGE peut déposer un projet éligible pour CADMOS. Ceci en tout temps. Il suffit de prendre contact avec l’auteur de l’article.

Remerciements Mes remerciements appuyés vont à Laurent Villard, Jonas Lätt, Christoph Bosshard, Ursula Röthlisberger, Simone Deparis et Alfredo Pasquarello pour avoir corrigé les paragraphes qui les concernaient.

Quelques références [1] CADMOS, www.cadmos.org.

[2] Marie-Christine Sawley, Les 5 Grand Challenges de l’EPFL, Hors-Série du Flash Informatique, EPFL, 1993. ditwww.epfl.ch/ SIC/SA/publications/FI93/FI_93.html.

[3] L. Formaggia, Alfio Quarteroni and A. Veneziani, Cardiovascular Mathematics, modeling and simulation of the circulatory system, ISBN: 978-88-470-1151-9, Springer, 2009.

[4] The BlueBrain Project, bluebrain.epfl.ch.

[5] LCBC, isic2.epfl.ch/page59069.html.

[6] ITER, www.iter.org.

[7] Le TCV au CRPP, crpp.epfl.ch.

[8] CSEA, itp.epfl.ch/page13360.html.

[9] CSE, cse.epfl.ch (voir article en page 16). n

MPI/PVM (Message Passing Interface/ Parallel Virtual Machine): normes définissant des bibliothèques de fonctions permettant d'exploiter le modèle par échange de messages &. MPI est devenu un standard de facto pour les machines parallèles homogènes (comme le BlueGene/P). PVM, de par sa capacité à faire communiquer un réseau de machine hétérogènes a été à la base de plusieurs projets comme la bibliothèque SCALAPACK. Il existe plusieurs implémentations de MPI (comme

MPICH, OpenMPI) et de PVM interfaçant les trois languages habituellement utilisé dans la haute performance C, C++ et Fortran ainsi que d'autres plus exotiques.

TF: TéraFLOPS représentant 10 à la puissance 12 opérations en virgule flottante à la seconde.

Analyse

La loi de Moore: quand s’arrêtera-t-elle ?

Christian.Piguet@csem.ch, Scientific Coordinator, CSEM Centre Suisse d'Électronique et de Microtechnique SA

This paper describes Moore's Law, as it was phrased in 1965 by Gordon Moore (Intel cofounder) including its modifications and interpretations. The big question is to determine when this Moore's Law will stop, as any exponential cannot exist for ever.

Cet article décrit la loi de Moore telle qu'elle a été formulée en 1965 par Gordon Moore (co-fondateur de Intel), ses reformulations et ses multiples interprétations. Cela permet ensuite de se poser la question de savoir jusqu'à quand cette loi va durer, car toute exponentielle est condamnée à s'arrêter une fois.

San Francisco, février 2003, à la plus grande conférence mondiale sur les circuits intégrés, les petites puces qui se trouvent dans vos appareils électroniques, Gordon Moore s’avance, la démarche plus très assurée, grandes lunettes, suivi très respectueusement par les grands pontes du comité d’organisation. 4000 personnes, moi y compris, observent. Grand silence: c’est lui, il arrive.

Respect, admiration, le grand, le célèbre Gordon Moore, celui qui a énoncé la loi de Moore, va s’adresser à l’assemblée pour évoquer ce fameux article de 1965, paru dans un obscur journal dont Intel recherche aujourd’hui activement l’original. Moore y avait prédit le doublement du nombre de transistors par puce, comme on le pense habituellement aujourd’hui, tous les deux ans.

De quoi parle-t-on au juste ? En 1947, à Bell Labs, William Shockley invente avec deux autres chercheurs les transistors, minuscules interrupteurs qui donnent vie aux puces. Il fonde alors une compagnie à Palo Alto, en Californie, qui marque les débuts de la Silicon Valley. Il engage le jeune Gordon Moore, qui le quittera bien vite pour fonder Fairchild avant d’être ensuite un des cofondateurs d’Intel. En 1965, encore à Fairchild, il écrit ce célèbre article de quatre petites pages dans Electronics, Vol. 38, No 8, 19 avril 1965. Et c’est là que le mythe commence: cet article prédit un doublement du nombre de transistors non pas tous les deux ans, comme on le dit aujourd’hui, mais chaque année.

En 1965, on pouvait fabriquer des circuits de quelques 50 ou 60 transistors; on aurait ainsi eu, selon Moore, 65’000 transistors par puce en 1975 avec un doublement chaque année.

Cette loi se vérifie assez bien jusqu’en 1970, en particulier pour les puces mémoires, plus denses que les microprocesseurs. Mais le premier microprocesseur de Intel, le 4004 fabriqué en 1971, ne comporte que 2000 transistors, et en 1976, le microprocesseur Intel 8085 n’en comporte que 6’000, relativement loin des 65’000 prédits. En suivant cette loi de doublement chaque année, on de-

vrait avoir aujourd’hui des puces de 2 millions de milliards de transistors, ce qui n’est évidemment pas le cas, puisqu’un microprocesseur moderne comporte aujourd’hui un peu plus de deux milliards de transistors !

Déjà en 1970, il apparaît clairement qu’on n’observe un doublement du nombre de transistors par puce que tous les 18 mois, et quelques années après, selon une période de 2 ans. Ce qui est tout à fait intéressant, c’est que l’on continue de parler de la loi de Moore, même en corrigeant son contenu ! Évidemment, Gordon Moore est alors un des co-fondateurs et patron de Intel, numéro un des microprocesseurs, et selon le vieil adage: on donne à ceux qui ont déjà. Même dans les articles scientifiques les plus sérieux, lorsque la loi de Moore est citée, on trouve tantôt un doublement tous les 18 mois, sorti on ne sait d’où, tantôt tous les 2 ans, et plus personne ne se rappelle vraiment ce qu’a dit Moore en 1965.

D’ailleurs, Moore lui-même reconnaît qu’il avait bien prédit une année en 1965, n’avait jamais parlé de 18 mois, mais bien de 2 ans par la suite. Il ne manquait d’ailleurs pas d’ironiser: «La loi de Moore est finalement donnée à tout ce qui est exponentiel, et si Gore a inventé Internet, moi j’ai inventé l’exponentielle !». Finalement, en observant le nombre de transistors des microprocesseurs de Intel, un doublement chaque année jusqu’en 1970, puis un doublement tous les 2 ans depuis cette date, se montre assez correct. Les plus gros microprocesseurs en 2010 comportent en effet un peu plus de deux milliards de transistors. Et les prédictions pour les quinze prochaines années font état de puces de 70 milliards de transistors en 2024.

Mais qu’a donc dit Gordon Moore lors de cette conférence à San Francisco en 2003 ? Toujours un peu ironique, il a affirmé que sa loi serait encore valable pour la présente décennie, mais que l’on peut toujours retarder le moment où une exponentielle s’arrête. Mais il est évident qu’un doublement chaque 2, 3 ou même 10 ans du nombre de transistors sur une puce ne peut durer éternellement. La question cruciale est donc de savoir quand cela va s’arrêter. Ou de savoir si d’autres éléments, analogues à des transistors, issus des nanotechnologies, vont plutôt remplacer ceux-ci. À la première question, les prédictions actuelles répondent que la microélectronique (transistors en silicium) a encore de beaux jours devant elle. Il est certain qu’il y a de formidables problèmes techniques à résoudre, comme la consommation d’énergie électrique.

En effet, la densité de chaleur sur une minuscule puce de microprocesseur atteint celle d’un réacteur nucléaire. Les interconnexions de milliards de transistors posent aussi de graves problèmes: il y a 8 à 10 couches de connexions métalliques les unes sur les autres, mais le temps de transmission des signaux sur ces fils devient trop grand par rapport à la vitesse exigée des mi-

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

5

La loi de Moore: quand s’arrêtera-t-elle ? croprocesseurs. Il y a beaucoup de travaux de recherche pour empiler des puces les unes sur les autres dans la 3e dimension pour éviter des interconnexions trop longues. Un autre problème est le coût de fabrication des puces et des fonderies qui les produisent, ce qui pourrait être un frein significatif à la microélectronique.

Néanmoins, les prédictions jusqu’en 2024 suivent toujours la loi de Moore, simplement parce que les puces actuelles contiennent plusieurs cœurs de processeurs travaillant en parallèle. L’effort de conception pour copier/coller plusieurs cœurs sur une seule puce est assez petit. Par contre, la répartition des tâches logicielles sur plusieurs cœurs est un problème très difficile. Néanmoins, la loi de Moore ne pourra pas durer éternellement: il y aura forcément un grand ralentissement au doublement du nombre de transistors par puce, lorsque l’on approchera des 10 nm, puis une saturation. Cela ne signifiera nullement la mort de la microélectronique. Combien d’industries sont florissantes même avec des progrès technologiques à peu près inexistants; l’industrie des montres mécaniques en est le plus parfait exemple. À la deuxième question, soit l’émergence des nanotechnologies, il est encore plus difficile de formuler une réponse pour les prochaines décennies. Des nano-éléments, de l’ordre de quelques nanomètres, analogues à des transistors ou des interrupteurs, ont déjà été fabriqués avec succès. On a même fabriqué de petits circuits réalisant des fonctions très simples basés sur des nano-éléments qui s’interconnectent par auto-assemblage, que ce soient des nanotubes de carbone, des interrupteurs moléculaires ou des automates quantiques. Il faut quand même souligner qu’en 2024, les transistors issus de la microélectronique auront des dimensions d’une dizaine de nanomètres, et donc qu’ils entreront aussi dans ce domaine des nanotechnologies. Le plus intéressant est que ces nano-éléments seront si petits que les électrons, grains qui forment le courant électrique, pourront presque se compter un à un, et que les effets quantiques vont intervenir à cette échelle.

Comme le soulignait le célèbre physicien Richard Feymann: «il y a plein de place en bas», soit dans l’infiniment petit. Ainsi la loi de Moore pourrait trouver une seconde jeunesse avec des puces comportant des centaines de milliards de nano-éléments.

Il est par contre peu vraisemblable que l’on puisse concevoir des circuits basés sur ces nano-éléments comme l’on conçoit nos microprocesseurs actuels. En effet, pour ces derniers, on suit un plan, débutant par l’établissement des spécifications du circuit, puis par les moyens de les satisfaire; c’est une méthode définie de haut en bas, comme quand on construit des maisons ou des ponts.

Pour les nano-éléments, c’est l’inverse: on les fabrique d’abord; ils sont auto-assemblés plus ou moins au hasard, et ensuite on détermine si ce que l’on a fabriqué est capable de réaliser une fonction intelligente. C’est un peu similaire à l’évolution dans le monde du vivant, une méthode définie de bas en haut. Il est donc probable que les éventuelles puces basées sur des nano-éléments seront totalement différentes de celles d’aujourd’hui, et seront loin de réaliser les mêmes fonctions. Peut-être ces futures puces auront-elles plutôt des fonctions analogues à celles du cerveau, caractérisées par une immense redondance. n

6 flash informatique

Analyse

Un mot: modèle — trois regards: art, informatique et illustrateur.

Les Pygmalion de l’ère high-tech – FJ Jadis l’artiste et son modèle, la poseuse et son Pygmalion formaient le couple mythique qui enfantait l’œuvre dans l’intimité de l’atelier. Depuis la haute antiquité – le moyen âge mis à part –, peintres et sculpteurs tournent autour du corps humain comme des prédateurs amoureux. Entre Vénus et odalisques, Adonis et Cupidon, le nu trône au panthéon de l’art occidental. L’académisme en fixe les références mythologiques, les poses et les canons de beauté idéale afin de canaliser les fantasmes et rassurer les protagonistes quant à la définition des rôles.

Léonard de Vinci est celui qui pousse l’étude le plus loin en allant –ultime striptease - jusqu’à disséquer les corps pour mieux en comprendre les formes et fonctionnements. Quelques siècles plus tard, Manet et Degas font scandale en congédiant Minerve et Junon pour déshabiller Justine et Amélie. Chez Rodin, les modèles nus, hommes et femmes, déambulent librement dans l’atelier.

Ils doivent poser sans poser, évoluer avec naturel. Le sculpteur croque au vol leurs attitudes et mouvements. Et au Bateau-Lavoir, on conseille aux femmes peu gâtées par la nature d’aller poser chez Picasso…

Vers 1850, les modèles sont à 4 francs la pose de 4 heures et la place Pigalle constitue un véritable marché aux modèles. Et dans les classes d’anatomie des écoles d’art, les étudiants en gilet et lavallière travaillent sur leurs chevalets disposés en cercle autour du modèle vivant. Mais il faut attendre la toute fin du XIXe pour qu’y soient autorisés des modèles féminins.

Et aujourd’hui ? Le modèle n’a pas disparu, mais il a changé de nature. Certes le grand Lucian Freud continue à peindre d’après modèles vivants – y compris la reine d’Angleterre – avec une puissance expressive ravageuse et sans complaisance. Certes Luc Tuymanns, Elisabeth Peyton ou le Lausannois Jean Crotti restent fidèles à une forme de figuration d’après modèles, fussent-ils des apparitions captées sur Internet. Quant à Bacon, il préférait travailler d’après photos plutôt qu’avec des modèles afin, disait-il, de ne pas opérer devant eux l’atteinte que je leur inflige dans mon œuvre.

Mais plus que par la peinture ou la sculpture, la figuration contemporaine passe par la performance (où l’artiste utilise son propre corps et se fait à la fois le sujet, l’objet et le support de son œuvre), la photographie (les portraits géants de Thomas Ruff ou les mises en scène de la Lausannoise Annaïk Lou Pitteloud) et la vidéo (l’Américain Bill Viola ou le Lausannois Jean Otth qui filme et réinvente en peintre l’éternel dialogue du peintre et son

Modèle Françoise Jaunin, f.jaunin@gmail.com, critique d'art Marco.Picasso@epfl.ch, EPFL – SB - professeur à la chaire d'analyse et de simulation numérique Esteban.Rosales@bluewin.ch, géologue et illustrateur

modèle). Quant au travail, il se fait moins en direct avec le vivant qu’en référence à un deuxième ou un troisième degré de la représentation, une mise en abyme de cette réalité que nous vivons le plus souvent par procuration, par image ou écran interposé.

Modèle – MP Pour le mathématicien appliqué que je suis, un modèle est un modèle numérique, soit le résultat des étapes suivantes.

Modélisation mathématique: il s’agit d’écrire des équations reliant les quantités inconnues (vitesse d’un fluide par exemple).

Selon le degré de complexité du phénomène, on aboutit à des équations différentielles ou aux dérivées partielles, déterministes ou stochastiques. Par exemple, les principes de conservation de la masse et de la quantité de mouvement d’un fluide Newtonien et incompressible conduisent aux équations de Navier-Stokes. La question de l’existence et de l’unicité d’une solution est aujourd’hui un des sept Millennium Prize Problems récompensé par US$1,000,000.

Résolution numérique: sauf cas particulier, il n’est pas possible de trouver une solution explicite du problème. Il convient

alors de proposer un algorithme permettant d’approcher les inconnues, algorithme qui pourra ensuite être implémenté sur un ordinateur. Dans le cas d’équations aux dérivées partielles on parle de schémas aux différences finies, volumes finis ou éléments finis. Le numéricien agit ici comme un système expert afin de choisir le bon algorithme, car il en connaît les propriétés théoriques, souvent démontrées sur des modèles simplifiés.

Implantation sur ordinateur et validation: vient alors le travail de programmation et de debugging, puis la phase de validation qui consiste à comparer la solution calculée sur ordinateur avec: 1 une solution explicite pour les cas simples; 2 d’autres résultats numériques; 3 les résultats d’une expérience.

Depuis les années 80, grâce à la constante augmentation de la puissance des ordinateurs, les modèles numériques ont fait irruption dans le monde industriel. Un ingénieur EPF modèle doit aujourd’hui savoir manipuler un modèle numérique. En particulier, il doit pouvoir mettre en perspective l’erreur du modèle mathématique, l’erreur de la méthode numérique et l’erreur de mesure commise lors de l’expérience. n

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

7

Analyse

Simulations go Live, a.k.a. in-situ visualization Jean M. Favre, jfavre@cscs.ch, CSCS (Swiss National Supercomputing Center), Visualization Software Engineer

L'écriture des fichiers des résultats de simulations numériques est depuis longtemps le goulot d'étranglement du calcul à haute performance. La visualisation in-situ permet à l'utilisateur de se connecter directement à une simulation en cours d'exécution, pour examiner les données et en faire des représentations graphiques. C'est donc un nouvel atout dans la course aux calculs de grande taille, en évitant le besoin d'écrire des données massives sur les disques.

Mais, c'est aussi une technique facile d'utilisation pour des calculs de taille plus restreinte, pour laisser l'ingénieur se concentrer sur le développement de l'algorithme numérique, en rajoutant une interface graphique en très peu d'effort.

Writing results of numerical simulations to disk files has long been a bottleneck in high-performance computing. In-situ visualization libraries enable the user to connect directly to a running simulation, examine the data, do numerical queries and create graphical output while the simulation executes.

It addresses the need of extreme scale simulation, eschewing the need to write data to disk. Yet, it can also be used on the desktop by anyone wanting to concentrate on coding an algorithm, and adding a graphical user interface in a few button clicks.

The annual Supercomputing conference (SC10) has just closed its doors. Several machines around the world are now beyond the 1 petaFLOPS range (one quadrillion floating point operations per second). Running simulations on these machines means using a computation distributed over 100,000 to more than several millions of processing elements. And writing results to disk files hits a major bottleneck. The access speed of disk drives is several orders of magnitude smaller than that of cpu-to-memory accesses. Future systems already in the design phase for the exascale era will only worsen this situation. (Read about the brutal facts of HPC at www.hp2c.ch/background/hpcfacts).

Thus, the need to eschew I/O to disk, in favor of in-situ visualization: visualize while the simulation is running, gaining direct access to the memory pointers of the simulation code, asking the simulation to do its normal iterative processing with regular checks to service visualization requests.

2010 is the first year that the Supercomputing Conference proposes tutorials in in-situ visualization. In fact, not just one, but two libraries in open-source form were demonstrated. The ParaView package proposes a co-processing toolkit [1] while the VisIt

flash informatique

package demonstrated its in-situ support with the libsim library [2].

This article will present the VisIt library, because it is much more mature, and easier to operate. But the fundamental operating modes are similar in both libraries.

Simulation codes and I/O Many scientific applications involve the solution of partial differential equations. These equations are discretized on a grid of cells or nodes and an approximation to the solution is generally found by iterating until a convergence threshold or when a maximum number of iterations is reached. What happens in between can be a long story. The programmer is faced with many challenges. Setting up the correct boundary conditions; iterating over the right data arrays; writing the data results in a format that is compatible with visualization tools. Given the availability of today’s computing platforms, the programmer is encouraged to try bigger and bigger computing challenges, and will sooner or later move to parallel computing. With it comes the challenge of doing parallel I/O to disk, and to do it efficiently. This is still today where simulation codes are less advanced, exacerbating the I/O bottleneck discussed above. Writing I/O code has also often been the last and least fun process in implementing numerical simulations. Researchers prefer concentrating their coding efforts into the numerical parts akin to their discipline, leaving the I/O for last.

In the 1990s, scientific visualization has flourished as a post-processing activity. Running computer simulation consisted in doing batch-oriented computation on large clusters or supercomputers, followed by interactive visualization. This led to the development of many application-driven file formats for archiving, and to the necessity to develop writing and reading programs to encode, and later decipher the data file contents. The interaction with disk files has been a mandatory and often painful fact of scientific visualization, before one could even create the first image. To make things even worse, the visualization hardware is traditionally smaller, or even much smaller than the supercomputing platform first used for the computations, and the time spent reading data from disk files can be the major performance hit preventing interactive data exploration, impeding data discovery.

Instrumentation What if one could directly visualize the progress of a simulation, with a live connection to the simulation code, being able to peek at any memory arrays and mesh structures, being able to confirm the correct simulation setup and iterations, without the need to save data to disk?

Simulations go Live, a.k.a. in-situ visualization z Establish the connection to the VisIt GUI. z Receive and serve requests for data queries. z Disconnect and let the simulation continue.

Our instrumentation of a FORTRAN95 simulation of a free-surface flow (FVRIVER) at CSCS required 68 lines of new source code. Not a big change in the main looping code!

Initialization

Serve a Visualization Request?

Data Access Solve Next Step Check for convergence or, end-of-loop

Exit fig. 1 – the control flow loop of a simulation instrumented for in-situ visualization

Compilation and flow control VisIt uses the basic client-server model, with a client running the GUI, and a parallel server [3]. The server runs an Engine Library where all the visualization algorithms are implemented. Running with an in-situ connection, consists in compiling and linking our simulation codes with the libsim library to gain access to VisIt’s Engine Library. One then uses VisIt’s client, the GUI component.

Any visualization query available through VisIt’s standard GUI is also available to the simulation. No previously defined visualization scenario must be encoded. At any time while the simulation executes, VisIt’s GUI will be able to connect and disconnect from it.

The main premise of in-situ visualization is to gain access to the memory contents of the simulation. Both C and FORTRAN simulations can be instrumented.

A second source code change to make is to enable read access to the pertinent data structures in the simulation code. All memory arrays can be advertized, enabling access to mesh and field variables, at any timestep, and for any parallel compute nodes participating in the simulation.

Meta-data information needs to be sent to the GUI. Meta-data are information about the mesh size, type and partitioning in the simulation, plus the number and type of variables available. This exchange of protocol with the GUI enables all the visualization techniques implemented for that type of data. For example, if a 2D rectilinear mesh with a variable called temperature is advertized, the user will be able to request a pseudo-coloring display of the surface, as well as iso-contour levels, histograms (etc…) of the scalar temperature.

Figure 2 shows such display. Source code for the Laplacian solver pictured here is available for your own testing [4].

Giving access to the temperature array (T) of the simulation above is done with few lines of code: ! FORTRAN code allocate (T(XX, YY)) nTuples = XX * YY visitvardatasetd( h, VISIT_OWNER_SIM, 1, nTuples, T) // C code float *T = malloc(XX * YY * 4); nTuples = XX * YY; VisIt_VariableData_setDataF( h, VISIT_OWNER_SIM, 1, nTuples, T);

fig. 2 – pseudo-color display of temperature at timestep 877 during the execution of a Laplacian solver

Implementing the execution control of Figure 1 might require some code re-organization, but the changes are usually small.

Loops are usually found in the execution path of a simulation, and we only need to add a few control lines to allow the following:

The single most-important thing to notice is the flag VISIT_ OWNER_SIM which indicates that the simulation code owns the memory pointer and is thus responsible for its deallocation.

The visualization server component, loaded via a run-time dlopen() call when the connection is first established, is then free to use the pointer in read-only mode, to construct the visualization requested. This is the best scenario, thanks to a linear and compact array allocation, requiring no memory duplication. There will however be other cases, when an existing simulation code has a predefined memory usage which presents data in a more distributed - fragmented - manner. Just think of memory allocations dispersed across many struct() or C++ class members. In that case, the driver needs to gather the memory objects into a compact array allocated on purpose, and the visualization is said to own the memory pointer gathering the data. The VISIT_OWNER_COPY would distinguish this case.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

9

Simulations go Live, a.k.a. in-situ visualization

Interaction with the simulation

tion is available in the Mandelbrot.C example of VisIt’s source tree.

In that demo, parameter inputs typed at the console, are used in future iterations to modify the number of levels and refinement ratio of the AMR grid used by the simulation.

Images Let us not forget the original goal of visualization: to make pictures. Once connected to a simulation, with a set of visualization representations selected on-the-fly at a given timestep, we can instruct the Visualization server to save images to disk while the simulation iterates. We are thus replacing a possible enormous 3D transient archiving of results of raw data, with a sequence of well defined visualization images.

Conclusion VisIt’s in-situ visualization support, a mature interface to parallel FORTRAN and C codes, is an answer to one of HPC’s fundamental road block towards increased performance at extreme scale. But it can also serve with modestly sized computations run on clusters, for anyone wanting to free himself from I/O and data formatting issues, to connect live, to a running simulation, and gain access to a myriad of visualization algorithms implemented and rigorously tested in VisIt’s main visualization library. The author wishes to encourage any scientist writing his or her simulation code to install the open source VisIt (it is now far easier than it used to be), instrument their source code with compilation flags to conditionally compile the VisIt in-situ support, and then launch their simulation and connect the GUI with it.

References Interaction with the simulation can be done through a command panel with buttons enabling iteration controls such as next, update, run, etc.

Besides visualization commands, a simulation code can also be instrumented to receive other types of inputs, such as parameters to influence the next steps in the simulation. The best demonstra-

[1] www.paraview.org/Wiki/SC10_Coprocessing_Tutorial; [2] visitusers.org/index.php?title=VisIt-tutorial-in-situ; [3] visitusers.org/index.php?title=500words; [4] portal.nersc.gov/svn/visit/trunk/src/tools/DataManualExamples/Simulations/contrib/pjacobi/ n

Water height above the river bed at two different timesteps during an in-situ visualization connection with the solver FVRIVER of Matthew Cordery at CSCS

10 flash informatique

Analyse

An optimized finiteelement library: Akantu Nicolas.Richart@epfl.ch, collaborateur scientifique, Guillaume.Anciaux@epfl.ch, collaborateur scientifique & Jean-Francois.Molinari@epfl.ch, professeur EPFL – Laboratoire de simulation en mécanique des solides

Akantu signifie petit élément en kinyarwanda, une langue bantoue. Désormais, c’est également une bibliothèque open-source orientée objets d’éléments finis, qui a pour ambition d’être à la fois générique et performante.

Akantu means a little element in Kinyarwanda, a Bantu language. From now on it is also an opensource object-oriented library which has the ambition to be generic and efficient.

Within LSMS (Computational Solid Mechanics Laboratory, lsms. epfl.ch), research is conducted at the interface of mechanics, material science, and scientific computing. We currently work on damage mechanisms, contact mechanics, and micro mechanics.

These domains imply studying phenomena at different scales, from atomic (nano-scale) to continuum (macro-scale). In order to understand the physics involved, we need ever more computationally intensive numerical simulations. For the macroscopic scale the finite-element method is a well established numerical method. However, as far as we know, there are no open-source projects that fulfill genericity, robustness and efficiency. Along these requirements Akantu was born.

The genericity is necessary to allow the easy exploration of mathematical formulations through algorithmic ideas. Furthermore, we believe that the open-source philosophy is important for any scientific software project evolution. Indeed, the collaboration permitted by shared codes enforces sanity when users (and not only developers) can criticise the implementation details. In addition, the understanding of complex physical mechanisms stands on the manipulation of huge data sets. Therefore, robustness and efficiency permit to push further the limitations imposed by the numerical simulations and more specifically in the context of parallel computation.

In order to achieve these goals, we made noticeable choices in

material virtual computeStress (in strain)

elastic computeStress (in strain)

plastic computeStress (in strain) fig. 1 – inheritance schematic of material classes

the architecture of Akantu. First we decided to use the objectoriented paradigm through C++. This paradigm is useful in terms of genericity and code factorization. In fact, it relies on the concepts of inheritance and polymorphism, which allow to identify the common interface of objects so as to define high-level classes.

These are to be derived in specialized classes. For instance, in the finite-element method, applied to solid mechanics, we need to compute different material laws. Most of them take strain as an input and compute the associated stress. In that case, the common interface to material objects contains a function that compute stresses from strains (see Figure 1).

The constitutive law is obviously not computed in the same way for every materials. Each material has to re-implement the function computeStress. The polymorphism mechanism allows the use of a common interface with any kind of material instantiated. It mainly relies on virtual function calls, which consist in finding the right function to invocate from the table containing all the implementations. Even though polymorphism provides an helpful tool to developers, there is an extra cost associated to virtual function calls that affects strongly the efficiency.

Then, virtual function calls should be limited to specific situations and avoided where critical sections of the program are executed.

In finite-element algorithms, in order to perform field manipulations, loops over elements are always necessary and form the critical sections. In these loops, virtual calls should be excluded in order to maintain good calculation times. To demonstrate this point, we will use the example of mesh objects, which are naturally part of every finite-element code. Two distinct architectures are now presented: first an all-object approach and then what has been used in Akantu to avoid virtual function calls.

A mesh is a set of elements that connect some nodes. Depending on the meshing process, these elements can be of different types (triangles in 2D, tetrahedra in 3D,...). The natural idea is to define a generic element class that describes a common interface. Then, any element can inherit from this common object description. In this view the element embeds a lot of intelligence. For example, one element should know how to integrate a given field. This approach, which forms a full object architecture, stores for each element a complex object which is also autonomous (see figure 2a). In any processing loop over elements, it will result in a virtual function call per element and lead to a drop of performance.

To improve this, while maintaining the usage of object oriented paradigm, we limit in Akantu the virtual calls to be outside of any loop. Inside a loop, the manipulated data structures are vectors.

For meshes, it means that elements, as a group, are represented by a vector of nodal coordinates and a vector of connectivities (see figure 2b). Global functions, like the integration procedure, operate on the entire set of elements. The counter part is that genericity is reduced when compared to a full object view: the high level classes contain now more complex functions.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

11

An optimized finite-element library: Akantu models steel during a normal compression. Comparative results are presented on figure 4.

a) Full object architecture Mesh elements

Element virtual interpolate () virtual integrate() connectivity nodes

b) Object/vectors architecture

connectivity nodes

fig. 2 – object architecture versus a mixed object/ vector architecture for a mesh class

In the case of the object/vector architecture, there are less virtual function calls but there are still potentially conditional jumps in the critical loops. Indeed, for a mesh containing different element types, an integration loop includes a decision per element to select the appropriate integration method. However, even a single if statement can decrease performances. Therefore, to be even more efficient, decisions should be avoided in loop contexts. The solution is to make choices outside of the loops. This will produce functions that are specialized to a typical situation. In other words the code needs to be vectorized.

In Akantu, the connectivities displacement have been sorted by element types so as to break loops over Gradient elements as said above. Concerning a complete finite-elestrain ment sequence, that contains gradient computation, conConstitutive law stitutive law call, integration and assembly, the vectorialistress zation imposes a specific task organisation. Global tasks can Integration be divided in simple operations and pipelined in order integral form to obtain the desired result, as shown in figure 3.

Assembly The crucial point here is that these SIMD (Simple Instrucresidual tion Multiple Data) operations fig. 3 – pipeline of vectorial operaare in fact well optimized by tions used to compute nodal resinowadays compilers. These duals from nodal displacements vectorial operations can also be ported easily on vectorial architectures such as modern GPUs. Nevertheless, the main drawback of this approach is the memory cost since we have to store partial results through the task pipe (strains, stresses, integral form, see figure 3).

In order to demonstrate the performance of our code and the relevance of our architecture choices, we made a comparison with another C++ finite-element code, OOFEM (Object-Oriented FiniteElement Model, www.oofem.org). In OOFEM the authors made the choice to use the object inheritance concept down to the lowest levels. Our comparison test case considers a meshed cube which

12 flash informatique

fig. 4 – comparative view between OFFEM and Akantu after 5000 time steps. The color shows the Z-axis displacement field

While the numerical results are very close, performance of Akantu appears to be 25 times faster. Thus, the choice of being very generic and of having a full object view has an important impact on the performance.

We used the same test case, and refined the mesh to get approximately 6.6 million elements, in order to do a scalability test of Akantu. The results are shown on figure 5. The scalability shows good behavior up to 32 processors. We also emphasize that a super scalar effect is observable with 4 processors. This must be due to communications overlap and important processor cache effects. The announced memory usage drawback appears not to be a real limitation. Indeed on a cluster considered as low memory (2Gb per octo-core) we managed to run a reasonably large case with approximately 3.3 million of elements, even in sequential.

64

Speedup Ideal speedup

32

16 Speedup

Mesh

8

4

2

1

1

2

4

8 16 Number of processors

32

64

fig. 5 – Speedup of Akantu library. The model manipulated is a cube meshed with 6 567 862 elements

We presented the main choices taken in the development of Akantu to achieve genericity and efficiency. We designed the library as an hybrid architecture with object at the high level layers and vectorialization for the low level layers. Thus, Akantu benefits the inheritance and polymorphism mechanisms without the counter part of having virtual calls within the critical loops. Even if the development is still at its onset, the first results seem encouraging. They tend to prove that these choices show nice performance speedup while our needs for genericity were maintained at a reasonable level. Soon (summer 2011 ?), the first release of Akantu will be out, with a set of tutorials that are thought to be the basis of a future educational program. In particular, Akantu tutorials will be added to the core finite-element classes, at the Bachelor and Master level of the Civil Engineering program. Furthermore, Akantu will be part of several research projects conducted within LSMS. n

Analyse

Simulations de systèmes astrophysiques au LASTRO Yves.Revaz@epfl.ch,

collaborateur scientifique, EPFL - SB – Laboratoire d’astrophysique

Astrophysics is an exciting area, based on complex and varied physics.

The HPC resources are essential tools to explore it.

L'astrophysique est un domaine passionnant, reposant sur une physique complexe et variée.

Les ressources HPC sont des outils indispensables pour l'explorer.

Les simulations numériques astrophysiques sont devenues incontournables pour étudier des systèmes physiques dont la taille et le temps dynamique dépassent complètement l’homme. Elles permettent de sonder une physique complexe d’un milieu dominé par la gravité, dont l’évolution est peu intuitive. Le laboratoire d’astrophysique de l’EPFL (LASTRO) est très actif dans ce domaine et utilise depuis plusieurs années des codes massivement parallélisés pour modéliser la formation et l’évolution des galaxies.

Le grave problème de la force de Newton Nous sommes sujets sur terre à un champ de gravité dont la source est la terre elle-même. Dans la plupart des expériences terrestres, ce champ peut-être considéré comme constant. En effet, la gravité générée par les autres composants impliqués dans l’expérience est en général très faible par rapport à la masse de la terre et donc complètement négligeable. Il n’en va pas de même dans l’espace. Les forces de gravité générées par les systèmes étudiés eux-mêmes ne sont plus négligeables. Souvent même, ces forces sont les forces dominantes, responsables de la structure et de l’évolution du système. Ces systèmes, dits auto-gravitants, regroupent la plupart des corps célestes bien connus, tels que les planètes, les astéroïdes, les étoiles et les galaxies.

Si la force de gravité, connue depuis Isaac Newton (1643-1727) est simple dans sa formulation, inversement proportionnelle au carré de la distance de la source, d’un point de vue numérique, son calcul est très gourmand en CPU. Contrairement aux forces intermoléculaires de type Van der Waals qui sont des forces à courte portée seulement, le calcul exact des forces gravitationnelles doit prendre en compte l’influence de toutes les masses, y compris celle des masses lointaines. Mais comme chaque masse sera elle même influencée par les autres, pour connaître, à un instant donné, l’effet de la gravité sur le système entier, le calcul devra s’effectuer un nombre de fois égal au nombre de masses du système. Si N masses sont considérées, le nombre de forces à calculer sera donc de l’ordre de NxN. Un algorithme subtil utilisant les ressources des GPU récents permet de calculer environ 1010 forces par seconde. Si l’on considérait

chacune des 100 milliards d’étoiles, il faudrait plus de 30’000 ans pour estimer le champ gravitationnel de notre Voie Lactée à un instant donné. Pour suivre son évolution sur plusieurs milliards d’années, le calcul devra être répété quelque 100’000 fois (en supposant que des pas de temps de 0.1 million d’années sont suffisants) !

Heureusement, ces nombres astronomiques peuvent être ramenés à des proportions plus humaines en considérant que: 1 Quelques centaines de milliers ou même quelques millions de particules sont souvent suffisantes pour saisir l’essentiel de l’évolution d’une galaxie. Dans ce cas, une masse (une particule massive) ne représente plus une étoile unique, mais une portion de l’espace, qui en plus des étoiles, peut contenir du gaz et des poussières.

2 Le calcul des forces peut-être approximé tout en respectant la longue portée de la force de gravitation. Par exemple, l’algorithme dit du treecode (Barnes 1986), réduit le nombre de forces à calculer à N log N (au lieu de N2). Cette méthode consiste à approximer certaines régions de l’espace par un développement multipolaire au premier ordre. L’approximation est justifée pour autant que la région soit suffisamment éloignée et compacte du point auquel les forces doivent être estimées. Les régions à approximer sont déterminées à l’aide d’une décomposition hiérarchique de l’espace en arbre qui a donné son nom à la méthode.

3 Le temps de calcul peut-être fortement diminué en utilisant un code parallélisé. Les codes les plus robustes tournent sans problème sur des centaines de cœurs.

La physique du milieu interstellaire Si la force de gravité domine les systèmes astrophysiques, dans certains cas il est nécessaire de tenir compte d’autres processus physiques.

Dans les amas de galaxies par exemple, le gaz est plus abondant que les étoiles. Les forces issues de gradients de pression doivent être prises en compte. Pour résoudre les équations de l’hydrodynamique, une méthode parfaitement adaptée à un système N-corps est la méthode SPH (Smooth Particles Hydrodynamics, Lucy 1977). Les particules composant le système ne sont plus vues comme des points matériels, mais comme de petits corps étendus.

Leur taille dépend de la densité locale. Plus la densité est élevée, plus la taille des particules sera petite. Ceci permet naturellement d’augmenter la résolution là où cela est nécessaire. Cette méthode dite lagrangienne est parfaitement adaptée à la simulation d’un système s’effondrant sous sa propre gravité. Les attributs hydrodynamiques associés à chaque particule sont calculés par une convolution avec les attributs des particules voisines.

Dans cette approche, toute grandeur est donc lissée, ce qui peut

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

13

Simulations de systèmes galactiques et extra-galactiques au LASTRO représenter un inconvénient majeur si la simulation présente des chocs, qui par définition sont discontinus.

D’un point de vue numérique, une grande partie du calcul des forces hydrodynamiques est consacrée à la recherche des plus proches voisins. Par chance, cette recherche peut s’effectuer efficacement en utilisant l’arbre issu de la décomposition hiérarchique de l’espace, nécessaire pour le calcul des forces gravitationnelles, suivant la méthode du treecode. L’hydrodynamique est complétée par la prise en compte de la perte d’énergie du gaz.

Au-delà d’une température de 104 K, ce qui n’est pas rare dans le milieu interstellaire, les électrons libres d’un gaz d’hydrogène ionisé peuvent se recombiner à leur atome et émettre un photon.

Comme le milieu interstellaire est suffisamment transparent, ces photons engendrent une perte nette d’énergie qui est loin d’être négligeable. Sous l’effet de sa gravité, le gaz peut alors se condenser, se fragmenter et former des étoiles. La formation d’une étoile s’opère dans des régions 10 millions de fois plus petites que la taille d’une galaxie. Suivre cette formation dans le détail dans des simulations de galaxies entières est hors de portée des codes actuels. Il faut alors recourir à des recettes empiriques qui décrivent la transformation du gaz en étoiles.

Les codes les plus raffinés permettent de suivre l’influence des étoiles sur la galaxie dans son ensemble. Les étoiles massives qui ont des vies relativement courtes (quelques millions d’années) finissent leurs jours dans une gigantesque explosion appelée supernova. Lors de ces explosions, le gaz des étoiles est disséminé dans le milieu interstellaire. Mais les propriétés du gaz éjecté ne sont plus celles existant lors de la formation de l’étoile, car durant toute sa vie, une étoile synthétise des nouveaux éléments chimiques, comme le fer ou le carbone, sans lequel la vie sur terre ne pourrait exister. L’apport de ces nouveaux éléments dans le milieu interstellaire modifie ses propriétés, en particulier sa capacité à se refroidir.

Code et stratégie de parallélisation Le squelette du code utilisé au LASTRO est basé sur le code Gadget-2 (Springel 05) auquel nous avons ajouté la description des processus physiques complexes du milieu interstellaire discutés plus haut. Le calcul des forces gravitationnelles est basé sur la méthode du treecode et l’hydrodynamique suit la technique SPH. Les deux méthodes sont parallélisées de la manière suivante: Dans un premier temps, l’espace est décomposé suivant une courbe fractale de Peano-Hilbert (voir fig. 1) tri-dimentionnelle.

L’avantage de cette décomposition est que les régions proches dans l’espace sont également proches le long de cette courbe.

Chaque processeur se voit attribuer une portion de cette courbe et traite les particules qui y sont associées.

fig. 1a – représentation bi-dimentionnelle d’une courbe de Peano-Hilbert.

14 flash informatique

fig. 1b – représentation tri-dimentionnelle d’une courbe de Peano-Hilbert.

Le calcul des forces gravitationnelles et hydrodynamiques est ensuite réalisé en plusieurs étapes: 1 Chaque processeur calcule les forces sur les particules locales, c'est-à-dire celles qui lui sont attribuées, en utilisant uniquement ces mêmes particules locales comme source du champ gravitationnel.

2 Si une particule nécessite de recevoir des forces supplémentaires, par exemple des forces dues à des particules associées à un autre processeur, cette particule est «exportée» vers ce dernier.

3 Les processeurs qui reçoivent des particules exportées complètent les forces en utilisant leurs particules locales comme source et les retournent ensuite au processeur qui les a envoyées.

La décomposition de l’espace doit être réalisée à chaque pas de temps. Cependant, comme les particules bougent en général peu entre deux pas de temps, peu d’échanges entre processeurs sont nécessaires pour redistribuer les particules. Cette méthode présente l’avantage de minimiser les communications et de partager parfaitement la mémoire. Par contre en raison des deux phases de calcul des forces (points 1 et 3) un load-balancing optimal est souvent difficile à obtenir.

Application aux systèmes astrophysiques Le code et les méthodes décrites ci-dessus sont applicables à différents types de systèmes astrophysiques. Nous décrivons ci-dessous quelques-uns d’entre eux qui ont fait l’objet de recherches par des membres du groupe du LASTRO.

La matière noire dans les galaxies spirales Depuis les années 70, l’étude de la rotation des galaxies nous indique la présence de matière sensible à la gravitation, mais qui n’émet aucun rayonnement. Cette matière appelée matière noire qui représente environ 90% de la masse d’une galaxie joue un rôle prépondérant dans la dynamique d’une galaxie. Cependant, très peu de contraintes existent pour sonder, non seulement la nature de cette matière, mais également sa distribution spatiale. En étudiant la forme des bras spiraux, en particulier, dans les régions les plus éloignées du centre, des simulations numériques de disques en rotation, ont permis de contraindre la distribution spatiale de

Simulations de systèmes galactiques et extra-galactiques au LASTRO cette matière. Contrairement à ce qui est prédit par les modèles cosmologiques, une fraction de la matière noire réside dans le disque des galaxies spirales, probablement sous forme d’un composant baryonique, faiblement dissipatif. L’auto-gravité de cette matière la rend très légèrement instable et engendre des bras spiraux détectés par l’observation de l’hydrogène neutre.

La formation des structures cosmologiques Le même code peut s’appliquer à des échelles cosmologiques.

Dans ce cas, rien moins qu’une portion d’Univers d’une taille équivalente à plusieurs dizaines de millions d’années-lumière est simulée.

fig. 2 – à gauche et au centre, distribution de l’hydrogène neutre dans la galaxie NGC6946, dans le modèle. À droite, distribution de la matière noire dans le modèle. Les spirales formées par la matière noire sont tracées par l’hydrogène neutre observé.

L’évolution chimique des galaxies naines Prendre en compte précisément la perte de masse des étoiles et suivre l’enrichissement en métaux du milieu interstellaire est plus que jamais d’actualité. Ces dernières années, grâce aux grands télescopes de l’ESO (European Organisation for Astronomical Research in the Southern Hemisphere, Chile), il a été possible de mesurer très précisément l’abondance de certains éléments chimiques présents dans des étoiles individuelles situées dans de petites galaxies (galaxies naines) proches de notre Voie Lactée (Tafelmeyer 2010). L’information contenue dans ces étoiles n’est rien moins qu’un traceur de l’histoire de la formation stellaire dans la galaxie. En couplant ces observations avec les résultats des simulations qui incluent non seulement l’évolution chimique, mais également la dynamique du système, un scénario complet et autocohérent de la formation et de l’évolution de ces objets peuxêtre obtenu (Revaz 2009).

fig. 4 – l’Univers après 1 milliard d’années, dans un cube de 300 millions d’annéeslumière de côté. La simulation contient 268’435’456 particules et représente 1 To de données. Les petits points rouges représentent la position des premières étoiles.

En partant d’un Univers très jeune (quelques millions d’années) et presque parfaitement homogène, les simulations permettent de suivre la croissance sous l’effet de la gravité de fluctuations initiales. De gigantesques structures émergent, sous forme de filaments.

fig. 5 – structures filamentaires formées par l’amplification gravitationnelles de fluctuation de densité. L’Univers simulé est ici âgé d’un peu plus de 6 milliards d’années.

fig. 3 – état d’une galaxie naine simulée, après 6.5 milliards d’années. De gauche à droite et de haut en bas, température du gaz, métallicité du gaz, luminosité des étoiles et distribution de la matière noire.

Les amas de galaxies se forment à la croisée de ces derniers. Dans des régions moins denses, on peut observer la naissance de disques galactiques. La comparaison entre les simulations et les observations permettent de vérifier la validité des modèles théoriques.

Elle permet également de fournir des contraintes sur certains mécanismes encore peu compris, par exemple l’énergie éjectée

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

15

Simulations de systèmes galactiques … lors de l’explosion d’une supernova, qui a un impact considérable sur le nombre et la luminosité des galaxies. Leurs prédictions sont également indispensables au design des futures missions d’observation (Baek 2009, Baek 2010).

Actualités

Master CSE: Vincent.Keller@epfl.ch, EPFL – CADMOS & Simone.Deparis@epfl.ch, EPFL – MATHICSE

Références Barnes, J. and Hut, P., A hierarchical O(N log N) force-calculation algorithm, 1986, Nature.

Lucy, L. B., A numerical approach to the testing of the fission hypothesis, 1977, Astronomical Journal, Vol. 82.

Springel, V., The cosmological simulation code GADGET-2, 2005, Monthly Notices of the Royal Astronomical Society, Volume 364.

Revaz, Y., Jablonka, P., Sawala, T., Hill, V., Letarte, B., Irwin, M., Battaglia, G., Helmi, A., Shetrone, M. D., Tolstoy, E., Venn, K. A., The Origin of the Diversity of Dwarf Spheroidal Galaxies, 2009, Astronomy and Astrophysics, Volume 501.

Revaz, Y., Pfenniger, D., Combes, F., Bournaud, F., Simulations of galactic disks including a dark baryonic component, 2009, Astronomy and Astrophysics, Volume 501.

Baek, S., Di Matteo, P., Semelin, B., Combes, F., Revaz, Y., The simulated 21 cm signal during the epoch of reionization: full modeling of the Ly-alpha pumping, 2009, Astronomy and Astrophysics, Volume 495.

Baek, S., Semelin, B., Di Matteo, P., Revaz, Y., Combes, F., Reionization by UV or X-ray sources, 2010, Astronomy and Astrophysics, Volume 423.

Tafelmeyer, M., Jablonka, P., Hill, V., Shetrone, M., Tolstoy, E., Irwin, M. J., Battaglia, G., Helmi, A., Starkenburg, E., Venn, K. A., Abel, T., Francois, P., Kaufer, A., North, P., Primas, F., Szeifert, T., Extremely metal-poor stars in classical dwarf spheroidal galaxies: Fornax, Sculptor, and Sextans, 2010, Astronomy and Astrophysics, Volume 524. n

Computational science is a multidisciplinary field connecting computer science with physics, chemistry, life sciences and engineering. For may years, it has been a strategic focus at EPFL. Several projects go towards this priority. We can mention CECAM (European Center for Atomic and Molecular Computations), recently installed on campus, and the collaborative Lemanic project CADMOS (Center for advanced Modeling Science), whose BlueGene/P supercomputer is the most visible part. Industry is also in need of computational science: several start-ups and spin-offs are issued from EPFL labs or created by our collaborators. This strong presence of computational sciences has been boosted last year with the creation of the Master in Computational Science and Engineering (CSE) that we introduce here.

Science multidisciplinaire par excellence, trait d’union entre l’informatique, les sciences de base (physique, chimie, sciences de la vie, finance, biologie, médecine) et l’ingénierie, la science numérique est placée depuis de nombreuses années en tête des priorités stratégiques de notre école. Que cela soit dans la recherche académique comme au CECAM (Centre Européen de Calcul Atomique et Moléculaire) récemment installé sur le campus ou au sein du projet collaboratif lémanique CADMOS (Center for Advanced Modeling Science, dont le supercalculateur BlueGene/P en est la partie la plus visible) ou dans l’industrie, avec plusieurs start-ups ou spinoffs sorties directement des laboratoires ou créées par des collaborateurs de l’EPFL, la science numérique est un choix d’avenir. Cette forte présence a été encore renforcée il y a un an par la création du Master en Science et Ingénierie Computationnelles (Computational Science and Engineering) que nous vous présentons ici.

La simulation numérique dans tous les domaines

Rencontre entre deux géants. Dans environ 4.5 milliards d’années, la grande galaxie d’Andromède devrait entrer en collision avec notre Voie Lactée. La simulation dont est extraite l’image, contient deux disques de 16 Millions de particules et a nécessité 40 jours de calculs sur 132 cœurs. La masse de données accumulée représente 4 To.

16 flash informatique

Grâce à l’arrivée de grappes de calcul et de supercalculateurs toujours plus puissants, l’horizon de la recherche et de l’industrie s’est considérablement étendu. Ces machines permettent de supplanter, parfois de remplacer, des bancs de test et des expériences très coûteuses, grâce à la simulation numérique. Qui n’a jamais entendu parler de l’avion Airbus A380 dont une large part des

un atout pour l’ingénieur du futur !

composants a été simulée avant d’être réellement construite et testée ? Qui ne connait pas ITER, le prototype de fusion thermonucléaire contrôlée pour la production d’énergie primaire dont les aspects de chauffage – notamment – sont analysés par la simulation numérique ? Qui n’a pas vibré aux exploits du défi suisse Alinghi lors des éditions de la Coupe de l’America et qui a profité de l’expertise de l’EPFL en matière de simulation numérique ? Que dire des avancées médicales grâce à la simulation numérique (par exemple la compréhension des mécanismes impliqués dans la maladie d’Alzheimer au niveau du système nerveux central) ou encore l’évaluation des risques grâce à la simulation de modèles financiers dans les sciences actuarielles ?

Tant sur le plan de l’ingénierie, de l’industrie, de la médecine ou de la recherche académique, les sciences numériques prennent une part de plus en plus prépondérante pour répondre aux défis de demain. La maîtrise des outils numériques représente un atout immense pour l’ingénieur. Le Master en Science et Ingénierie Computationnelles est le point d’entrée dans ce monde.

De la modélisation à la simulation Le Master se déroule en deux années et comprend des cours, des projets de semestre et de Master ainsi qu’un stage en entreprise. Le curriculum académique se divise en deux, avec d’un côté les cours de base et de l’autre les cours dédiés aux diverses applications de la simulation numérique. Les cours de base permettent au candidat d’acquérir les outils indispensables, tels que l’algorithmique avancée pour le calcul scientifique, les méthodes numériques, l’architecture et la technologie des ordinateurs, la programmation multi-processeurs, la modélisation multi-échelle et multi-physique. Les cours dédiés aux applications permettent à l’étudiant d’approfondir ses connaissances dans des domaines spécifiques de la science et de l’ingénierie tels que la mécanique

des solides et des fluides, la chimie moléculaire et quantique, la biologie, le traitement du signal ou encore la finance. Ces cours avancés sont donnés par des professeurs et chargés de cours de diverses facultés de l’EPFL (Sciences de Base, Sciences et Techniques de l’Ingénieur, Informatique & Communications ou encore ENAC) offrant un large spectre des domaines où la simulation numérique est intensément utilisée.

La direction scientifique du Master est assurée par un comité de pilotage composé de sept professeurs de notre école, dont la directrice du CECAM, et trois provenant des universités partenaires du projet CADMOS, soit les universités de Genève et de Lausanne.

Un adjoint scientifique assiste les étudiants dans le choix des cours, des projets et dans la recherche d’un stage en entreprise.

Les débouchés de ce Master sont nombreux dans l’industrie (développement logiciel, ingénierie environnementale, analyse financière et bancaire, chimie et pharma). Pour rapprocher nos étudiants (en Bachelor, en Master, ou à l’école doctorale) de l’industrie, la section de mathématiques a organisé pour la première fois une soirée de rencontre, avec notamment des présentations des directeurs du CECAM et du CADMOS, ainsi que des chercheurs de Nestlé et de CALCOM/ESI, exemples d’entreprise de l’arc lémanique pour lesquelles les sciences computationnelles sont un outil important des R&D (Recherche et Développement). Du côté de la recherche académique, il constitue une forte base pour un Doctorat en Science numérique.

Un mineur en CSE Il est à noter enfin qu’un Mineur accompagne le Master en Science et Ingénierie Computationnelles pour les étudiants qui ne voudraient pas réorienter complètement leurs études après le Bachelor, mais qui ressentent l’importance de compléter leur formation par des cours et des projets dans ce secteur. n

40e Workshop en Calcul Haute Performance et Tutoriel sur la visualisation 12-13 Septembre 2011, Université de Bâle Ce workshop est organisé par la Société Speedup.

Durant ce workshop, les conférenciers présentent et discutent l’état de l’art des domaines du calcul haute performance et du calcul scientifique.

Les conférences se concentrent sur l’algorithmique et les défis logiciels concernant le calcul haute performance.

Il y aura aussi une séance de posters, encouragez vos collaborateurs à participer!

Plus d’informations sur www.speedup.ch.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

17

Analyse

Qu’est-ce qu’InfiniBand ?

David Cervini, cervini0@etu.unige.ch, étudiant à l'Université de Genève

With 42.6% of the Top500 supercomputers featuring an InfiniBand interconnect type, the InfiniBand architecture has become very popular in HPC, but also in other domains like databases and storage.

This article introduces the concepts and advantages of InfiniBand.

Avec 42.6% de machines dans le Top500 possèdant une connectivité InfiniBand, ce type d'architecture est devenu très populaire en HPC, mais aussi dans d'autres domaines comme les bases de données ou le stockage. Cet article présente les concepts et les avantages d'InfiniBand.

L’Architecture InfiniBand (IBA) décrit une technologie d’interconnexion entre nœuds de calcul et leurs périphériques d’entrée-sortie. Il en résulte un réseau SAN & (System Area Network) basé sur les switches, indépendant du matériel et de l’OS des hôtes.

L’ IBTA (InfiniBand Trade Association), fondée en 1999, est dirigée par un comité incluant IBM, Intel, Mellanox, Oracle, QLogic et Voltaire. Son but est de maintenir et de faire évoluer la spécification d’InfiniBand. Dans cet article, une présentation des avantages d’InfiniBand (IB) et du concept d’IB sera faite.

Puis nous verrons comment deux nœuds communiquent, ainsi que la composante matérielle majeure. Finalement, les spécificités de la couche Liaison du réseau IB seront abordées.

Avantages d’InfiniBand InfiniBand possède les avantages suivants: faible latence: 1 μs mesurée pour une communication d’hôte à hôte; bande passante élevée 40 Gbits/s de bout-en-bout du réseau et 120Gbits/s de point à point, avec de la fibre optique; bon marché: le matériel InfiniBand a un meilleur rapport prix/puissance que les autres alternatives; faible consommation d’énergie.

Concept d’InfiniBand Traditionnellement, l’OS (système d'exploitation) gère les ressources liées aux réseaux. Lorsqu’une application souhaite y accéder, il lui fournit le service voulu à travers une interface réseau.

L’application dépend donc de l’OS qui lui fournit les services relatifs à l’utilisation du réseau.

Le principe d’InfiniBand est de libérer l’OS de la surcharge liée à la copie des données de l’espace d’adressage de l’application vers ce-

flash informatique

lui lié au réseau (zero copy feature). Cela se fait par le InfiniBand messaging service: une application y accède directement courtcircuitant ainsi l’OS (stack bypass).

InfiniBand relie une application et son espace d’adressage directement à une autre application et son espace d’adressage.

Communication de bout en bout du réseau Les Queue Pairs

InfiniBand interconnecte directement deux applications et leur espace d'adressage virtuel entre elles. Celles-ci peuvent se trouver sur deux machines différentes (NIC = Network Interface Controller)

Une extrémité de la communication est appelée Queue Pair (QP).

Les applications accèdent au InfiniBand’s messaging service via les QP et communiquent par des verbs &.

L’application doit avoir un accès direct à ses QP (une par connexion) afin de court-circuiter l’OS; pour cela, les QP sont joints à l’espace d’adressage virtuel de l’application. De cette manière, une application a accès directement à la mémoire virtuelle de l’autre application (de manière contrôlée).

Opérations exécutées par les QP Il y a seulement 2 types d’opérations possibles: z SEND/RECEIVE au sens usuel; z RDMA READ/RDMA WRITE. Les opérations SEND/RECEIVE sont le plus souvent utilisées pour le transfert de messages de contrôle, notamment dans la mise en place des opérations RDMA READ/RDMA WRITE. Une opération RDMA permet à une application d’accéder directement à un espace mémoire de l’autre l’application.

Host Channel Adapter Le HCA (Host Channel Adapter) est un périphérique matériel qui connecte un nœud au réseau InfiniBand. Il permet aux applications d’accéder au réseau: les QP fournissent aux applications le moyen de contrôler le HCA.

Qu’est-ce qu’InfiniBand ?

En effet, on voit sur la figure que les QP sont les interfaces entre la mémoire de l’application et le HCA. Un système de MTP (Memory Translation & Protection) effectue la correspondance adresse virtuelle/physique et valide les droits d’accès.

Ici, on définit deux LID pour tous les HCA, de façon à utiliser un FAT TREE entre les switches contenant LFT 1 et les 2.x.

Cela permet de transiter en parallèle sur deux brins entre le switch supérieur et les deux autres.

LFT 1 ____________ DLID Port A1 1 A2 2 B1 1 B2 2 C1 3 C2 4 D1 3 D2 4 E1 3 E2 4

1 2 3 4

LFT 2.1 ____________ DLI Port A 3 A 3 B 4 B 4 C1 1 C2 2 D1 1 D2 2 E1 1 E2 2

1 2 3 4 5

A1/A2

1 2 3 4 5

B1 /B2

C1/C2

D1 /D2

E1 /E2

LFT 2.2 ____________ DLID Port 1 A1 A2 2 1 B1 B2 2 C1 3 C2 3 D1 4 D2 4 E1 5 E2 5

Le HCA remplace donc l’OS dans l'exécution des requêtes réseau des applications.

Il existe des algorithmes de routage tirant parti des VL pour permettre plusieurs chemins pour une même destination: UP/DOWN (voir [1]) et LASH (voir [2]) par exemple.

Les spécificités de la couche liaison

Conclusion

Virtual Lanes & qualité de service

L’idée d’InfiniBand est de court-circuiter l’OS en assistant le CPU par une autre composante matérielle: le HCA accessible par les applications. Les domaines tels que le HPC (high-performance computing), voir figure ci-après, les scale-out database environments, le shared and virtualized I/O se tournent de plus en plus vers InfiniBand. En effet, InfiniBand s’impose de plus en plus dans le top 500 [3]: 28% (dont le numéro 1) en novembre 2008 contre 42% (dont le numéro 3) en novembre 2010!

Il s’agit d’un mécanisme créant plusieurs chemins virtuels au sein d’un simple lien physique. À chaque VL (Virtual Lane) est associée une paire de buffers (Transmit et Receive).

Chaque port (un lien physique relie 2 ports) possède de 2 à 16 VL. À chaque VL est associé un niveau de service (Service Level).

Cette correspondance est gérée par l’administrateur réseau qui configure les tables de correspondance (des ports) SL à VL.

Gigabit ethernet

Il a pour rôle d’empêcher la perte de paquets lorsque le buffer de réception est plein. Chaque port gère un contrôle de flux indépendant pour chaque VL. Il se fait par un système de crédit: chaque destinataire possède un crédit indiquant la quantité de données que l’émetteur est autorisé à envoyer depuis l’initialisation de la liaison, évitant ainsi la perte de paquet due au phénomène de congestion. Étant donné que chaque Virtual Lane possède une paire de buffers propres, ce système s’applique à chaque paire.

400 Machines

Contrôle de flux point à point

500

Infiniband

Myrinet

other interconnect

300

200

100

0 1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

100

Routage Le routage par les switches est statique: la destination des paquets constitue un chemin à travers les switches. Chaque switch contient une Fowarding Table associant à chaque destination (DLID) un port de sortie. La création de celle-ci, l'assignation des LID (Local ID) aux nœuds (HCA inclus) et plus généralement la configuration des nœuds du réseau sont gérés par le SM (Subnet Manager).

Chaque nœud communique avec le SM par le SMA (Subnet Management Agent).

Les communications entre nœuds et switches se font en point à point. Puis il suffit de suivre les ports de sortie des tables de routage, comme on le voit sur l’exemple.

% Flops

80

60

40

20

0

évolution des proportions des familles d'interconnect dans les machines du Top500. On remarque depuis 2003 une prolifération de l'InfiniBand.

Je vous recommande la lecture de Introduction to InfiniBand for End Users [4] expliquant les concepts de base ou encore le chapitre 3 de InfiniBand Architecture Specification [5] décrivant plus en détail tous les aspects de l’architecture d’InfiniBand.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

19

Qu’est-ce qu’InfiniBand ?

Bibliographie

[5] InfiniBand™ Architecture Specification Volume 1. Release 1.2.1. www.InfiniBandta.org. n

[1] P. Lopez, J. Flich and J. Duato. Deadlock-free Routing in InfiniBand through Destination Renaming. IEEE; [2 Tor Skeie, Olav Lysne and Ingebjorg Theiss. Layered Shortest Path (LASH) Routing in Irregular System Area Networks. IEEE; [3] Liste des 500 superordinateurs les plus performants selon le benchmark LINPACK: www.top500.org; [4] Paul Grun. Introduction to InfiniBand for End Users.

InfiniBand Trade Association, www.InfiniBandta.org;

GLOSSAIRE

&

SAN (System Area Network): système de réseaux à ne pas confondre avec le même acronyme SAN (Storage Area Network): réseau de stockage.

Verbs: ils décrivent les opérations qu'une application peut effectuer sur les QP: création, soumission d'une requête, récupération du résultat et configuration du Channel Adapter.

HPC Advisory Council Switzerland Workshop 2011 Lugano – March 21-23, 2011 The Swiss National Supercomputing Center (CSCS) and The HPC Advisory Council will host the HPC Advisory Council Switzerland Workshop 2011 in the Lugano Convention Center, Lugano Switzerland.

The workshop will focus on HPC education and training including networking, storage, GPU technologies and various applications.

Four sections will be included every day: z High Speed Networking, z High Speed storage, z MPI deep dive, z Advanced technologies GPUs. The workshop will bring together system managers, researchers, developers, students and industry affiliates for cross-training and to discuss recent HPC developments.

Web: www.hpcadvisorycouncil.com/events/2011/switzerland_workshop/

CSCS Swiss National Supercomputing Centre

the Swiss HPC Service Provider Community hpc-ch est la communauté des administrateurs système HPC de Suisse.

Cette communauté se rencontre deux fois par an lors de Forums pour échanger les expériences et discuter les développements dans le HPC. Chaque Forum a un thème. Voici un aperçu des thèmes passés: z décembre 2009 Université de Zurich First hpc-ch Forum: Getting Together; z mai 2010 EPFL Operating Systems for HPC and Installation Methods; z octobre 2010 ETHZ Parallel file systems for HPC. Les deux prochains Forums ont déjà été agendés: z mai 2011 PSI Schedulers and Queuing Systems; z octobre 2011 Université de Bâle GPU and Accelerators.

En outre des Forums, hpc-ch organise des rencontres lors des grandes conférences et des présentations sur des thèmes autour du HPC. Pour plus d'informations, vous pouvez visiter le site Web de hpc-ch: www.hpc-ch.org.

20 flash informatique

À votre service

Unification de logins et système de files d’attente

L’expérience SuperB Vittoria.Rezzonico@epfl.ch, EPFL - SB-IT, spécialiste HPC et responsable de la salle serveur de la Faculté des Sciences de base

Computing clusters have lately become so common that every lab performing research involving HPC wants to have its own. However, the multiplication of small local clusters also increases the administration burden – for instance, each cluster has its own authentication method, and users belonging to more labs see their accounts multiply. Moreover, at a given moment, one cluster may be overbooked while the others are under used. In this article, we describe a procedure to unify logins and queues in order to overcome these problems while keeping each cluster’s independence.

Les clusters de calcul sont devenus tellement courants que chaque laboratoire dont la recherche nécessite des calculs souhaite en avoir un. Par contre, la multiplication des petits clusters augmente le fardeau administratif. Par exemple, chaque cluster a son propre système d’authentification et souvent les utilisateurs collaborant avec plusieurs unités observent une multiplication de leurs comptes. De plus, à un certain instant, un cluster peut être surbooké pendant que les autres sont vides. Dans cet article, nous décrivons une procédure d’unification de logins et files d’attente qui nous a permis de résoudre ces problèmes tout en gardant l’indépendance de chaque cluster.

La Faculté des Sciences de Base compte dans sa salle machine à peu près 20 clusters de laboratoire. Les membres de la FSB soit appartiennent à une unité qui possède un cluster, soit demandent un compte sur un cluster partagé (DIT, Pleiades).

Le DIT met à disposition les ressources HPC suivantes [1]: z quatre clusters centraux, dont trois à accès payant et un à accès gratuit; z un BlueGene/P [2]; z une grille de calcul, à accès gratuit; z des plates-formes expérimentales à accès gratuit.

De plus, le cluster partagé Pléiades [3] est accessible moyennant une taxe d’entrée.

Les clusters de laboratoire sont achetés pour avoir du temps de calcul à la demande et de façon instantanée. Comme ils appartiennent à un petit groupe de personnes, ils sont parfois sous-utilisés. Les membres du laboratoire ont accès à ces ressources, et les collaborations entre unités font que certaines personnes ont une multitude de comptes. Depuis août 2007, la plupart des clusters des laboratoires sont administrés au niveau facultaire. Ceci nous a

permis d’identifier les problèmes pratiques (comme les utilisateurs qui oublient qu’ils ont accès à plusieurs ressources) ou simplement économiques (charges inégales dans les différents clusters).

En janvier 2009, nous avons décidé de récupérer les cycles CPU perdus sur nos clusters, et plusieurs solutions étaient envisageables: z insérer les clusters dans la grille de l’EPFL; z unifier les clusters en un gros cluster hétérogène auquel n’importe qui ayant payé une partie aurait accès; z introduire un super-master qui s’occuperait uniquement de l’authentification et du scheduling.

La grille de calcul de l’EPFL [4] compte à peu près 1300 machines hétérogènes, lesquelles sont utilisées par leur propriétaire le jour et sont mises à disposition pour des calculs la nuit, quand les propriétaires ne les utilisent pas. La plupart de ces machines se trouvent dans les salles pour étudiants. Vu la nature de la grille de calcul, les jobs y tournant doivent: z être mono-processeur; z durer au maximum 4 heures (avec possibilité de checkpointing); z être soit compilés, soit utiliser Matlab, R, Maple, Octave ou PovRay. Certains utilisateurs ne sont pas gênés par les restrictions imposées, mais beaucoup d’utilisateurs de la FSB souhaitent lancer des calculs dont la durée dépasse 8 heures. De plus, ils ont exprimé le besoin d’exécuter parfois des petits jobs parallèles. À cause de la nature des clusters pré-existants (appartenance à un labo), les joindre en une seule entité poserait trop de défis administratifs et politiques. En outre, les propriétaires préfèrent que seuls des membres de la FSB aient accès à leurs nœuds.

Les raisons indiquées ci-dessus conduisent à opter pour la dernière option: ajouter un Super-Master gérant les files d’attente et l’authentification.

Avant SuperB Début 2009 nous avons décidé de fédérer 4 clusters; chacun était installé comme suit: z Linux Debian Etch, upgrade à Debian Lenny planifié, z authentification NIS, chaque master étant un serveur NIS indépendant, z home directories exportées par NFS depuis le master, z système de queues (gestionnaire de ressources et ordonnanceur de tâches) installés sur chaque master. Plusieurs files d’attente existent pour chaque cluster, mais les utilisateurs ne doivent rien spécifier – une file de routage distribue les jobs dans la bonne file d’exécution en fonction des propriétés du job (nombre de processeurs, droits de l’utilisateur, temps CPU demandé). Un mapping entre queues et nœuds est défini. Les files d’attente sont gérées par Torque (partie gestionnaire de ressources) et Maui (ordonnancement).

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

21

Unification de logins et système de files d’attente: l’expérience SuperB

Buts Nous aurons deux types d’utilisateurs dans notre système: z les utilisateurs propriétaires qui appartiennent à un laboratoire qui a acheté du hardware; z les utilisateurs invités qui n’ont rien payé pour le matériel.

Les utilisateurs pré-existants ne doivent remarquer aucune différence entre l’ancien et le nouveau système. De plus, ils doivent être capables de se connecter sur n’importe quel master et lancer des exécutions sur leurs propres nœuds, ainsi que sur des nœuds appartenant à d’autres labos.

Les utilisateurs invités doivent avoir la possibilité de lancer des jobs sur n’importe quel nœud du système, et doivent avoir un home directory.

Authentification, identification et home directories Les home directories de chaque cluster doivent être montés par tous les clusters. Donc chaque nœud master doit donner accès dans le répertoire /home: z aux homes sur le master lui-même, z aux homes montés depuis les autres masters, À cet effet nous configurons un serveur NIS sur le Super-Master et nous utilisons autofs pour monter les homes.

Soumission de jobs Les jobs des propriétaires des clusters doivent tourner comme si les invités n’étaient pas là: z dans une queue, les jobs des propriétaires s’exécuteront toujours avant ceux des invités (priorité absolue); z quand un nœud est occupé par des jobs d’invités, et que le propriétaire souhaite exécuter les siens, les jobs des invités doivent céder la place.

Les invités doivent pouvoir lancer des jobs depuis le Super-Master, afin de ne pas polluer les masters pré-existants.

La solution: SuperB – le Super-Master de la FSB Le Super-Master (dorénavant appelé SuperB), joue le rôle de serveur master NIS. Un serveur Torque et le Scheduler Maui y sont aussi installés. En plus, SuperB héberge les home directories des invités.

les clusters charon et kobal et le Super Master SuperB

Pour décrire la configuration du système, nous allons simplifier un peu la vraie configuration actuellement en production. Pour cet article, les clusters préexistants s’appellent charon et kobal.

22 flash informatique

Charon a un master (serveur de gestion + home directories) et un front-end séparés en plus des nœuds de calcul. Le master de kobal fait aussi lieu de front-end. Kobal a aussi ses nœuds de calcul. La figure montre la configuration détaillée de charon, kobal et SuperB.

Le serveur NIS Les masters de charon et kobal seront configurés comme esclaves NIS de SuperB. Les nœuds de calcul utiliseront comme serveurs NIS leur master et SuperB.

Les homes directories Les répertoires homes seront accessibles au chemin /home/username depuis tous les nœuds et les frontends, et seront stockés dans /srv/home/username sur leur master, ou sur SuperB si l’utilisateur est un invité.

Chaque machine utilisera autofs pour faire le montage: z en mode bind si la machine est un master et si l’utilisateur a son home stocké dessus; z sinon via nfs.

La map auto.home sera distribuée par NIS depuis SuperB.

Le système de queues et le scheduler Avant l’intégration dans SuperB, chaque cluster avait des files d’attente définies selon les souhaits de ses propriétaires. Ces files d’attente seront transférées sur SuperB, qui par conséquent en aura une quantité non négligeable. Une modification très mineure du code source de Maui a été nécessaire pour pouvoir accommoder cette quantité non standard de données de configuration des files d’attente. file d'attente qui a accès

nombre de noeuds auxquels la queue a accès

batch

tout le monde

l0+l1+l2+i0

institut0

membres de l'institut i0

inst0lab0

membres du lab0

l0 + i0

inst0lab1

membres du lab1

l1 + i0

lab2

membres du lab2

l2

fig. 2 – exemple de queues dans SuperB. Si un institut finance des nœuds, tous ses labos y auront accès. Donc, si un labo de l'institut achète ensuite ses propres nœuds, il aura accès en même temps aux nœuds du labo et à ceux de son institut.

Dans la figure 2 on remarque une queue batch à laquelle tout le monde a accès: c’est la queue dédiée aux invités. Rappelons-nous que les jobs non-batch ont priorité absolue sur les jobs batch et que ces derniers doivent céder la place aux jobs des propriétaires si nécessaire. Pour cela on utilisera la fonction de preempting présente dans Maui. La préemption consiste à interrompre un job pour le reprendre ou relancer plus tard. Comme le checkpointing n’est pas possible dans notre cas, nous nous contentons d’interrompre brusquement le job par un signal KILL, et ensuite le remettre dans la queue (sauf indication explicite par le propriétaire lors de la soumission du job). Malheureusement, Maui ne permet le preempting que sur certains jobs (voir Preemprive Backfill [5]).

Ceci a demandé une adaptation du scheduler qui ne va pas être traitée dans cet article.

Unification de logins et système de files d’attente: l’expérience SuperB Par défaut, la queue de routage enverra le job dans la file la plus restrictive (celle du labo). Si on est propriétaire et que l'on souhaite forcer le job à aller par exemple dans la queue /batch/, il faudra le spécifier.

Routing Par définition, les seules parties visibles d’un cluster sur le réseau sont le front-end et éventuellement le master. Chaque cluster étant indépendant de chaque autre, aucune machine ne voit tous les nœuds directement. Ceci signifie que SuperB ne voit pas les nœuds. Pour que notre système tienne la route, il faut corriger cela, en rajoutant manuellement les routes vers les nœuds sur SuperB: #Kobal@ route add -net 192.168.19.0 netmask 255.255.255.0 gw X.Y.Z.19@ #Charon@ route add -net 192.168.7.0 netmask 255.255.255.0 gw X.Y.Z.7@

En plus de pouvoir contacter les nœuds directement, il faut que SuperB reconnaisse leur adresse IP. Un cluster par définition masque les paquets pour qu’ils apparaissent provenir du master.

Les firewalls de kobal et charon doivent donc être adaptés. Par exemple, le firewall de Kobal devient: iptables -À FORWARD -i lan0 -s 192.168.19.0/255.255.255.0 -j ACCEPT@ iptables -À FORWARD -i wan0 -d 192.168.19.0/255.255.255.0 -j ACCEPT@ iptables -t nat -À POSTROUTING -o wan0 -d X.Y.Z.254/32 -j ACCEPT@ iptables -t nat -À POSTROUTING -o wan0 -j SNAT --to X.Y.Z.19@

La 3e règle du firewall spécifie que la source des paquets en direction de SuperB ne doit pas être modifiée, contrairement à la 4e ligne qui dit de manipuler la source en l’indiquant comme pro-

venance du master. La 3e règle étant appliquée avant la 4e (first match), les paquets en direction de SuperB ignoreront la 4e.

Des modifications additionnelles sont requises pour lancer des jobs MPI à travers plusieurs clusters, mais comme ceci est déconseillé pour plusieurs raisons (plus de complexité dans le preempting, nœuds hétérogènes,…), elles n’ont pas été implantées.

Conclusions L’expérience SuperB est une évolution par rapport à la situation précédente. Toutes les fonctionnalités de plusieurs clusters isolés ont été implantées, et les utilisateurs peuvent travailler comme si SuperB n’avait jamais été introduit. En plus, on peut offrir du temps CPU pour des calculs séquentiels, mais aussi pour des petits calculs en parallèle Seul problème, le scheduler Maui n’est pas très robuste dans cette configuration: il doit d’une part être augmenté par le script de préemption, et en plus il ne supporte pas bien les grosses charges (plus de 5000 jobs en attente par exemple). Une étude est en cours pour envisager un possible changement de scheduler.

Tout membre de la FSB peut demander un compte sur SuperB: il suffit de s'adresser à l'auteur de cet article.

Références [1] Voir hpc-dit.epfl.ch [2] Voir www.cadmos.ch [3] Voir pleiades.epfl.ch [4] Voir greedy.epfl.ch [5] Quinn Snell, Mark J. Clement, and David B. Jackson.

Preemption based back-fill. In JSSPP ‘02: Revised Papers from the 8th International Workshop on Job Scheduling Strategies for Parallel Processing, pages 2437, London, UK, 2002. Springer-Verlag.n

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

23

À votre service

Une grille de calcul nationale Pascal.Jermini@epfl.ch, EPFL – Domaine IT

A computing grid is set up in Switzerland to provide computational resources to solve scientific computationally intensive problems.

Une grille de calcul se met en place en Suisse pour offrir des ressources à des problèmes scientifiques très gourmands en calcul.

Vous connaissez probablement déjà Greedy [1], la grille de calcul déployée sur le campus de l’EPFL. C'est maintenant au tour du SMSCG (Swiss Multi-Science Computing Grid) [2], une grille de calcul au niveau national.

SMSCG est un Working Group de SwiNG [3] (l’association de grille nationale Suisse) et est financé au travers du programme AAA/ SWITCH [4]. La première phase du projet a démarré en mai 2008 et s'est terminée en mars 2010. Le projet se trouve actuellement dans sa deuxième phase (qui a commencé en avril 2010), et se déroulera jusqu'en décembre 2011.

Le but de ce projet est de construire une infrastructure de calcul scientifique en tant que réseau de service de calcul et de données, de personnes, ainsi que de connaissances.

L’infrastructure actuellement déployée harmonise les ressources de calcul éparpillées dans plusieurs institutions académiques, et permet des échanges très fructueux d’informations parmi les participants.

Il n’y a pas uniquement l’aspect calcul dans ce projet, mais bien toute l’infrastructure qui va autour. Par exemple des outils de surveillance (monitoring) de l’infrastructure ont été développés, ainsi que des modules de comptabilisation de l’utilisation des ressources (accounting). En plus de l’aspect purement technique, SMSCG interagit avec d’autres projets de grilles nationales ou internationales.

Dès qu’un projet dépasse les frontières d’un domaine administratif (ou d’une institution), plusieurs problèmes commencent à émerger, notamment l’authentification et l’autorisation des utilisateurs par rapport à l’accès aux ressources. Le projet SMSCG se base beaucoup sur l’infrastructure SWITCHaai (Authentication and Authorization Infrastructure), que la majorité des utilisateurs de SMSCG connaissent déjà, étant donné que toutes les institutions participant au projet y sont rattachées d’une manière ou d’une autre.

La pièce maîtresse de l’infrastructure est le middleware ARC (Advanced Ressource Connector) [5], qui permet le partage et la fédération de ressources de calcul et de stockage distribuées sur différents domaines administratifs. Ce middleware présente l’avantage de pouvoir s’interfacer très facilement avec des gestionnaires de ressources locaux (LRMS: Local Ressources Manager

24 flash informatique

System), telles que Sun Grid Engine ou Condor. Ceci est un aspect important, étant donné l’hétérogénéité des systèmes à connecter.

Plusieurs applications sont prédéployées sur SMSCG, notamment dans le domaine de la biochimie (GAMESS, NAMD), de la géophysique (Alpine3D) ou de la biologie (Rosetta). Ce prédéploiement permet aux utilisateurs d’accéder aux applications de manière uniformisée, sans se soucier des particularités locales. Le déploiement d’autres applications reste possible, une fois que leur aptitude a s’exécuter dans l’environnement SMSCG a été évaluée. Si nécessaire, le projet offre aussi une équipe de support pour assister les utilisateurs à porter leurs applications et simulations sur l'infrastructure de calcul.

L’EPFL participe à cet effort national, en mettant à disposition une partie des ressources de calcul de Greedy, notamment la composante mono-coeur de la grille. Parmi les autres partenaires de SMSCG, nous pouvons compter sur des universités cantonales (Berne, Genève, Lugano et Zürich) des écoles d’ingénieurs (HESSO), le SIB (en particulier Vital-IT), SWITCH et l’Institut fédéral de recherches sur la forêt, la neige et le paysage (WSL).

SMSCG est ouvert à toutes les institutions académiques suisses, autant à la contribution qu’à l’utilisation des ressources mises à disposition. Les personnes de l'EPFL intéressées, peuvent contacter le groupe de support local (grid-admins@groupes.epfl.ch), tandis que les utilisateurs d'autres institutions peuvent prendre contact directement avec smscg-wg@swing-grid.ch.

A court terme, SMSCG vise aussi à explorer et implémenter l'aspect data management de la grille de calcul, étant donné que l'un des ingrédients des simulations sont les données à traiter. Il est donc aussi nécessaire de les transporter et stocker de manière efficace, ce qui en fait un sujet à part mais indispensable, que le projet souhaite aborder en 2011.

Sur le moyen long terme, ce projet, en collaboration avec SwiNG, vise à construire et maintenir une infrastructure de calcul pour la Suisse, tout en y harmonisant l’accès. Cet objectif est l’un des piliers de la stratégie globale de SwiNG.

Références [1] greedy.epfl.ch [2] [3] [4] [5]

www.smscg.ch www.swing-grid.ch www.switch.ch/aaa/ www.nordugrid.org/arc/ n

À votre service

Calculons au DIT !

Michela.Thiemard@epfl.ch, EPFL - Domaine IT

The DIT offers a variety of computing resources to the scientific community, from a supercomputer down to a computing grid. A brief overview is presented here.

Le DIT offre des ressources de calcul variées à la communauté scientifique, du super-calculateur à la grille de calcul. Un bref survol est présenté ici.

Une des missions du DIT est d’offrir des ressources de calcul à la communauté scientifique de l’EPFL. En 2010, les ressources disponibles se décomposent en cinq catégories: 1 un super-calculateur, 2 des clusters généralistes, 3 un cluster à grande mémoire, 4 des clusters expérimentaux, 5 une grille de calcul.

Une description détaillée de toutes ces ressources est disponible sur la page Web: hpc-dit.epfl.ch des ressources centrales, mais nous allons en faire un rapide survol.

Blue Gene/P

?

Cell/B.E

?

Jupiter

?

Vega

?

Antares

?

Callisto

?

Callisto, Antares & Vega Trois clusters généralistes sont accessibles.

Callisto, datant de juin 2008, est constitué de 128 nœuds biprocesseur quadri-cœur (quad-core) Intel Harpertown à 3.0GHz, avec chacun 32GB de mémoire, reliés par un réseau rapide de type InfiniBand à 20 Gb/s.

Antares, une extension de Callisto, mise en production début 2010, est constitué de 56 nœuds bi-processeur quadri-cœur (quad-core) Intel Nehalem à 2.66GHz, avec chacun 24GB de mémoire, reliés par le même réseau rapide InfiniBand que Callisto.

Vega, mis en production début 2010, est un cluster de 24 nœuds bi-processeur quadri-cœur (quad-core) Intel Harpertown à 2.66GHz, avec chacun 16 GB de mémoire, reliés par un réseau Gigabit Ethernet.

Contact: [callisto, antares, vega]-admins@groupes.epfl.ch Web: hpc-dit.epfl.ch/generalpurpose.php.

Jupiter

?

GPUs NVIDIA

des universités de Genève et de Lausanne ainsi que de l’EPFL. Vous pouvez trouver, en page 2 de ce journal, un article sur CADMOS et l’utilisation de Blue Gene/P. Contact: bg-admin@groupes.epfl.ch Web: bluegene.epfl.ch.

Greedy

2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 Contrat de support complet par le constructeur Hors contrat de support par le constructeur. En cas de panne matérielle la réparation n’est pas garantie

vue temporelle des serveurs

Blue Gene/P Ce super-calculateur, arrivé en août 2009, appartient au consortium CADMOS (Center for Advanced Modeling Science) et est hébergé et administré par le DIT. Il est accessible aux membres

Jupiter n’est pas seulement la plus grande planète de notre système solaire, mais également le cluster qui vient d’arriver et qui a la plus grande quantité de mémoire par nœud. Ce petit système, en termes de nœuds, est constitué de deux nœuds bi-processeur, octo-cœur (octo-core) Intel Nehalem-EX à 2.26 GHz, avec chacun 320 GB de mémoire, reliés par le même réseau rapide InfiniBand que Callisto et Antares.

Ce cluster sera mis en service début janvier 2011.

Contact: jupiter-admins@groupes.epfl.ch Web: hpc-dit.epfl.ch/highmemory.php.

Les clusters expérimentaux Afin de tester de nouvelles technologies, le DIT offre l’accès à de petits clusters expérimentaux. Actuellement nous en avons deux, un de processeurs Cell/B.E. et un autre de GPU. Le cluster de Cell/B.E. est constitué de 2 nœuds bi-processeur quadri-cœur (quad-core) Intel Harpertown et de 4 nœuds bi-processeur IBM PowerXCell 8i à 3.2 GHz et 8 GB de mémoire, reliés par un réseau rapide InfiniBand.

Le cluster de GPU est formé de 4 nœuds de calcul standards Intel Nehalem à 42 GB de mémoire et de 2 nœuds NVIDIA Tesla S1070

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

25

Calculons au DIT !

Analyse

comprenant chacun 4 GPU et 16 GB de mémoire, également reliés par un réseau rapide InfiniBand.

Contact: dit-exp-clusters-admins@groupes.epfl.ch Web: hpc-dit.epfl.ch/experimental.php.

Greedy La grille de calcul est une ressource bien différente d’un cluster standard. Son but est de récupérer les cycles de calcul non utilisés sur les PC des salles des étudiants et des collaborateurs. C’est par conséquent une ressource décentralisée et non dédiée, car le propriétaire des nœuds de calcul est toujours prioritaire sur toute activité calculatoire. Greedy est disponible depuis mi-2006 et compte à ce jour environ 1’200 cœurs aussi bien Windows, Linux que Mac OSX et plus de 8’000’000 d’heures de calcul y ont été récupérées.

Cette année, 80 machines mono-cœur ont été ajoutées à l’infrastructure. Ce sont des machines virtuelles à 2.5Ghz avec chacune 3GB de mémoire installées sur les anciens serveurs de l’infrastructure virtuelle du DIT. Ces nœuds sont un peu différents des nœuds traditionnels de Greedy, car ils sont dédiés au calcul.

Contact: grid-admins@groupes.epfl.ch Web: greedy.epfl.ch & greedy.epfl.ch/scc.php.

Politique d’accès aux ressources En décembre 2008, une nouvelle stratégie HPC a été acceptée par la direction. Sur les serveurs de calcul du DIT, elle est concrètement appliquée de la manière suivante: z Vega, Greedy et les clusters expérimentaux sont gratuits et libres d’accès pour les membres des institutions du CEPF ou pour les personnes collaborant avec de telles institutions. z Callisto, Antares, Vega et Jupiter sont financés par les utilisateurs. Les règles exactes sont disponibles sur le Web. z L’accès à Blue Gene/P est directement géré par CADMOS. Quelles que soient vos besoins en calcul, nous nous ferons un plaisir de vous aider et de vous conseiller dans le choix de la ressource la plus adaptée. n

Le DIT vous forme... et vous souhaite d’excellentes fêtes de fin d’année !

En 2011, parmi notre palette complète de cours, vous trouverez également des cours HPC: z DIT HPC servers usage (in English) N° 11-0174 – March 24 z MPI, an introduction to parallel programming (in English) N° 11-0016 – from April 5 to 8 z MPI, introduction à la programmation parallèle (en français) N° 11-0017 – du 12 au 15 avril.

Consultez régulièrement le site Web: dit.epfl.ch/cours, vous y trouverez tous les cours pour le 1er trimestre et pour plus de renseignements n’hésitez pas à nous contacter.

L’équipe des cours, cours.dit@epfl.ch.

26 flash informatique

Since 1993, the small world of high performance computing focuses nearly exclusively on the publication of the top500 [1] lists during the International Supercomputing Conference in June and SuperComputing in November to rank the worldwide supercomputers. Since June 2008, the top500 list proposes an estimation of the energy consumption of the supercomputers. Along the top500 list, another one based on the same benchmark (HPL) named green500 classifies the supercomputers on the basis of their energy consumption. But, is it possible today to build a machine which consumes 1 Joule per GFLOPS for a BLAS2-dominated code, around 4 to 5 times better than the best green BLAS3 solutions ? We try to answer this question by a thought experiment.

Depuis 1993, le petit (et le grand) monde du calcul scientifique se concentre presque exclusivement sur la publication bisannuelle de la liste du top500 [1] lorsqu’il s’agit de déterminer si un superordinateur est digne de figurer dans la classe des machines dites de haute performance ou pas. Depuis juin 2008, la liste comporte aussi une estimation de la consommation électrique des superordinateurs. Parallèlement, une liste verte – la liste green500 - basée sur le même benchmark (HPL) que le top500 classe les superordinateurs selon leur efficacité énergétique.

Peut-on aujourd’hui déjà, construire une machine qui consommerait 1 Joule pour 1 gigaFLOPS pour un code dominé par des opérations BLAS2, soit 4 à 5 fois moins que les meilleures solutions vertes ciblées sur BLAS3 ? Nous vous proposons une petite expérience de pensée pour y répondre.

Efficacité computationnelle ?

Si l'on s'enhardit à classer les applications scientifiques selon leur type, on s'aperçoit bien vite que celles qui trustent la première place (entre 75% et 80% à l'Université de Zürich[2], chiffre similaire mesuré à l'EPFL[4]) sont celles qui sont dominées par des accès mémoire. En simplifié, les opérandes ne peuvent être gardés en cache, chaque instruction requiert un accès à la mémoire haute.

On appelle ce type de noyau – de nain selon la nomenclature de Berkeley[3] – une opération de type BLAS2. Hors, la classification top500 régulièrement citée en référence utilise un noyau de type BLAS3 (le benchmark HPL[5]) qui, s'il est correctement configuré,

Entre efficacités computationnelle et énergétique

HPC@GreenIT Vincent.Keller@epfl.ch, EPFL, CADMOS & Ralf.Gruber@a3.epfl.ch, EPFL

permet de tirer la performance maximum d'un nœud de calcul.

On a même entendu dire que les constructeurs de chips ajoutaient quelques portes logiques et transistors ciblés à leur hardware pour pouvoir exploser la performance du benchmark HPL. En terme d'efficacité computationnelle, à savoir le rapport entre la performance mesurée et la performance maximale, le benchmark HPL atteint une valeur proche de 90% alors que les applications de la vraie vie n'en tirent pas plus de 10% à 15% dans les meilleurs cas, bien moins sur les processeurs multi-cœurs (moins de 5% est une valeur mesurée sur des quad-cœurs[4]). Premier constat donc, la réalité des applications devraient pousser le monde du calcul scientifique vers des suites de benchmarks qui reflèteraient l'efficacité computationnelle des applications du monde réel plutôt qu'un benchmark conçu à l'origine pour les architectures vectorielles. C'est le cas de HPC Challenge (HPCC) [6] ou de la plus complète NASA Benchmark Suite (NPB) [7]. Pour la suite de cet article, nous utiliserons le benchmark SMXV, il consiste en une multiplication matrice-vecteur qui, pour une taille de vecteur suffisamment grande (au-delà de la taille du cache L2) mesure exactement la bande passante mémoire puisque requérant exactement un accès à la mémoire haute – un LOAD – pour chaque instruction.

Efficacité énergétique ?

L’efficacité énergétique se définit comme le rapport entre ce qu’on peut tirer utilement d’un appareil divisé par la consommation énergétique totale de celui-ci. En informatique en général, en sciences computationnelles en particulier, l’efficacité énergétique se décrit comme le rapport entre la performance d’une application divisée par la quantité d’énergie pour la faire tourner. À nouveau arrive le problème de savoir ce que nous entendons par application et donc performance. Comme il est facile de tricher avec des courbes de speedup pour les applications parallèles (en mesurant une valeur catastrophique pour la quantité 1 en fonction de laquelle l’accélération est calculée), il est tout autant aisé de présenter des processeurs plus efficaces qu’ils ne le sont en réalité. Ainsi, si nous jetons un œil à la liste green500 (basée sur le benchmark HPL), le classement fait ressortir des valeurs de l’ordre de 1.6 GF/W pour le prototype du BlueGene/Q à IBM Watson à environ 1 GF/W pour les machines hybrides (composées de CPU conventionnels et de GPUs ou de Cell/B.E.). Au-delà du fait qu’il eut été plus judicieux de mesurer la valeur énergétique (en Joules) plutôt que la puissance crête (en Watt), on voit que les meilleures machines sont capables de fournir 1.6 GF/J pour le benchmark HPL, on estime à moins de 160 MF/J sur une vraie application (10% d’efficacité computationnelle). La question qui se pose immédiatement: est-il possible de construire une machine avec la technologie existante qui serait capable de produire 1 GF sur une

application réelle dominée par la bande passante mémoire et qui consommerait 1 J ? Nous proposons une réponse positive sous la forme d’une expérience de pensée basée sur les données d’une carte graphique Nvidia GTX280.

Une expérience de pensée Dans toute expérience de pensée, nous devons présenter les hypothèses de travail sur lesquelles elle se base. Nous avons choisi de prendre comme référence la carte graphique Nvidia GTX280, une carte graphique capable d’être programmée pour le calcul (GPGPU). Voici nos hypothèses de travail: 1 Il est possible d’isoler chacun des Nvidia cores .

2 Il est possible de modifier la fréquence d’horloge de chacun des cœurs.

3 Le processeur de texture est identique électroniquement aux autres Nvidia cores 4 La consommation énergétique d’une carte graphique se divise en trois parties égales: la mémoire haute, les GPUs et le reste de la carte.

5 Le prix de la carte graphique se décompose en trois parties égales: 33% pour la mémoire haute, 33% pour les GPUs et 33% pour le reste.

6 1 Watt sur 1 an coûte 1 franc suisse.

7 La durée de vie d’un superordinateur est de 4 ans.

8 La consommation électrique d’un chip (technologie CMOS) est fonction de la fréquence de fonctionnement au carré. Cela signifie que si l’on divise par deux la fréquence, le gain en énergie est d’un facteur 4.

Pour commencer, il s’agit de décrire la carte graphique GTX280 à partir de ces hypothèses. En voici les principales caractéristiques que nous utilisons dans notre expérience de pensée: z 10 GPU à 24 Nvidia cœurs chacun ce qui représente 240 cœurs Nvidia au total; z la fréquence de fonctionnement est de 1.3 GHz; z la performance maximum (peak performance) est de 78 GF pour des opérandes à virgule flottante en double précision; z la performance BLAS2 (multiplication matrice-vecteur avec taille suffisamment grande) est de 10 GF; z 4 GB de mémoire haute, une bande passante mémoire de 15 Gmots/seconde; z puissance électrique requise: 236 W (350 W si l’on considère le refroidissement); z coût: 400 CHF. L’expérience de pensée se déroule en trois phases distinctes. Dans les trois cas, l’on estime la performance et la consommation énergétique en utilisant le benchmark SMXV. La première phase consiste en la mesure de la performance et de la consommation

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

27

HPC@GreenIT: entre efficacités computationnelle et énergétique énergétique de la carte out of the box. Durant la seconde phase, on divise la fréquence des 10 GPUs par 4 tout en réduisant de 4GB à 1 GB la taille de la mémoire haute. Pour contrebalancer cette perte, on multiplie par 4 le nombre de cartes GTX280. Finalement, lors de la troisième phase, on éteint les cœurs inutiles, on ne conserve donc plus que 10 cœurs actifs sur les 240 d’origine.

possible avec le matériel d’aujourd’hui, de construire un nœud de calcul – et donc une machine parallèle composée de ces mêmes nœuds – capable de fournir une performance soutenue (sustained performance) sur un benchmark proche des applications réelles et consommant moins de 3 J par GF. 3 Joules c’est l’énergie requise pour soulever une pomme de 3 mètres dans le champ de gravitation terrestre selon Wikipedia.

Quelques remarques tout de même

Phase 1 1 x GTX280 1.3 GHz 4 GB memory 240 cores

Phase 2 4 x GTX280 0.375 GHz 1 GB memory per card 4 x 240 cores

Phase 3 4 x GTX280 0.375 GHz 1 GB memory per card 4 x 10 cores

Finalement on estime le coût de chacune des phases sur les quatre années de fonctionnement d’un nœud de calcul ainsi conçu. Les résultats se déclinent dans le tableau 1.

Machine

GTX280

GTX280 ¼F

GTX280 ¼ F, 1 core per GPU

NGPU

10

10

10

Ncores

24

24

1

F [GHz]

1,3

0,375

0,375

R∞ [GF]

78

19,5

6,5

17,7

4,43

4,43

M∞ [Gw/s] Mnode [GB]

4

1

1

RSMXV [GF]

10

2,5

2,5

W [W]

236

11

6,5

24

4,4

2,6

+50% AC**

36

6,6

3,9

Coût [CHF]

1800

1600

1400

W/R

SMXV

[J/GF]*

* énergie par GF sur le benchmark SMXV ** additionné de 50% de la valeur W/R SMXV pour le refroidissement (AC=Air Conditioning ou Air Conditionné). 50% correspond à un PUE de 1.5 (PUE=Power Usage Effectiveness). tableau 1 – expérience de pensée: les trois phases. Une carte qui possède 1GB de mémoire haute au lieu de 4GB ne coûte plus que 300 CHF au lieu de 400 CHF. Le coût final est calculé sur 4 années et en tenant compte que lorsque la fréquence et la taille de la mémoire sont divisés par 4, il s'agit d'acquérir 4 cartes.

Le premier constat qui saute aux yeux, c’est la bande passante exceptionnelle de la carte GTX280. C’est grâce à la conception de la carte que le benchmark SMXV atteint une telle performance.

La seconde conclusion difficilement imaginable, c’est le coût moyenné sur 4 ans. Quatre fois plus de matériel qui tourne quatre fois moins vite coûte 23% moins cher pour une performance équivalente sur le benchmark SMXV. L’efficacité énergétique est meilleure d’un facteur 9 (24/2.6) et est la cause de ces résultats prometteurs. La troisième conclusion est qu’il est

28 flash informatique

Qui dit quatre fois plus de matériel, dit qu’une densification des composants est obligatoire. D’autant plus qu’une bonne partie de l’électronique n’est pas utilisée. Cela signifie en d’autres termes une meilleure gestion du packaging du nœud de calcul.

Cela reste possible, l’expérience Blue Gene a montré avec succès qu’une densification des composants lorsque ceux-ci ne dégagent pas énormément de chaleur est possible.

Un autre effet indésirable de baisser la fréquence des processeurs, est que lorsqu’on se trouve dans le cas des derniers 30% d’applications non dominées par la bande passante mémoire, la performance baisse dramatiquement et la quantité d’énergie augmente.

Pour y remédier, il doit être possible de pouvoir overclocker les processeurs à la demande. Cela se fait déjà aujourd’hui dans le domaine de l’informatique embarquée et mobile (via la technologie DVFS). Une instrumentalisation (monitoring en anglais) de l’utilisation de la machine non intrusive, bas niveau, en temps réel et continue est donc fondamentale. Des premiers résultats prometteurs sont présentés dans HPC@GreenIT [4].

Conclusion La lutte contre le gaspillage de cycles de calcul mène à une lutte contre le gaspillage énergétique. Le meilleur moyen de ne pas gaspiller des cycles de calcul c’est avant tout de ne pas les produire. Un processeur multi-cœurs qui tourne une application scientifique dominée par les accès mémoire va n’utiliser qu’un seul cœur pour le calcul et tous les autres pour chauffer l’atmosphère. Cet article traite de cet aspect. Mais il y a de nombreux autres moyens d’économiser de l’énergie: l’optimisation des codes, l’optimisation du choix des machines en fonction des besoins des applications ou encore la parallélisation de codes. Tous ces éléments sont abondamment abordés dans le livre HPC@GreenIT [4] publié cette année.

Références [1] Classification top500: www.top500.org [2] Vincent Keller, Ralf Gruber, One Joule per GFlops for BLAS2 now !, proceedings of ICNAAM2010, Rhodes, Greece, AIP, pp.

1321-1324, 2010 [3] Berkely dwarfs, view.eecs.berkeley.edu/wiki/Dwarfs [4] Ralf Gruber, Vincent Keller, HPC@GreenIT, Springer, ISBN 978-3-642-01788-9, 2010 [5] High Performance LINPACK, www.netlib.org/benchmark/hpl [6] High Performance Computing Challenges, icl.cs.utk.edu/hpcc [7] NASA Parallel Benchmark, www.nas.nasa.gov/Resources/ Software/npb.html n

Analyse

On-chip cooling using micro-evaporators Jackson.Marcinichen@epfl.ch, Jonathan.Olivier@epfl.ch & John.Thome@epfl.ch, EPFL – STI – Laboratoire de transfert de chaleur et de masse

With energy consumption becoming a huge concern amongst hardware manufacturers and data center operators, novel solutions to reduce this consumption needs to come to light. Cooling of microprocessors is one of the largest areas where improvements can be gained. The LTCM lab’s decade of experience with two-phase cooling research for computer chips and power electronics will be described. Flow boiling in multi-microchannel cooling elements made of silicon, copper or aluminium have the potential to provide high cooling rates (up to as high as 350 W/ cm2), stable and uniform temperatures, microprocessor hot spot management while being compact and thus minimizing the fluid inventory. This cooling technology can bring about savings of more than 50%, with further potential savings being made if the heat were to be recovered.

Cooling of data centers can represent up to 45% [1] of the total energy consumption using current cooling technologies (air cooling). In the US, this relates to an estimated 45 billion kWh usage by 2011 with an annual cost of $3.3 billion, or $648 billion with the inclusion of a carbon tax. And this is just for cooling. Most data centers make use of air-cooling technologies to ensure the correct running of the servers contained within. The limits of aircooling, however, are being approached due to the performance

increase in the microprocessors (CPU) in the servers, which will have heat fluxes in the order of 100 W/cm2 in the not too distant future. It was shown that air has a maximum heat removal capacity of about 37 W/cm2 [2]. The problem is made worse with servers being more densely packed, such as blade centers, racks that will be generating in excess of 60 kW of heat, while today’s data centers are designed for cooling capacities in the order of 10-15 kW per rack [3]. Hence, if data centers want to become green, other solutions to air-cooling are required.

10

◆ Microchannel- Single-phase ■ Porous Media - SP ▲ Porous Media - TP ✫ Jet Impingement ✳ Microchannel- Two-phase

✳

✳ ✳ ✳ Rhs,Kcm2/W

La consommation d’énergie devenant un problème important pour les fabricants de matériels informatiques et les opérateurs de serveurs, de nouvelles solutions sont nécessaires pour réduire cette demande. L’amélioration des techniques de refroidissement des microprocesseurs est un des domaines où les plus grandes avancées sont possibles. L’expérience du LTCM dans le refroidissement par système bi-phasique des systèmes microélectroniques, longue de dix ans, est décrite. Les évaporateurs à multi-canaux fabriqués en silicium, cuivre ou aluminium peuvent refroidir de très hauts flux de chaleurs (jusqu’à 350 W/cm2), assurer la stabilité et l’uniformité des températures et permettre la gestion des points chauds sur un microprocesseur tout en étant compacts et en minimisant la quantité de liquide requise. Ce système de refroidissement peut réduire la consommation d’énergie de plus de 50%, avec d’autres gains possibles lorsque la chaleur est récupérée et utilisée à d’autres fins.

1

✳ ✳

✳

✳

■

✳

✳

✳

▲

✳

◆

✳ ✳

✳ ✳

0.1

▲

✳

■

◆◆

▲

✫ ✫

✫

■

◆

✫ ✳ ◆

■

◆

◆

✫

0.01 1.0E-07

1.0E-06

1.0E-05

1.0E-04 1.0E-03 Qp/Qt

1.0E-02

1.0E-01

1.0E+00

fig. 1 – thermal resistance of heat sinks for diverse cooling technologies as a function of the pump to the dissipated power ratio.

One solution is to go to direct on-chip cooling. Recent publications show the development of primarily four competing technologies for on-chip cooling: microchannel single-phase flow, porous media flow, jet impingement and microchannel two-phase flow [4]. Leonard and Philips [5] showed that the use of such new technology for cooling of chips could produce savings in energy consumption of over 60%. Figure 1 shows the heat sink thermal resistances for diverse cooling technologies as a function of the pumping power to the dissipated thermal power ratio. The best heat sink solution should be that nearest the lower left corner because it represents the lowest thermal resistance at the lowest pumping power. It is clear that two-phase microchannel cooling is the best performing technology.

The LTCM lab in particular has a very extensive research program on all important aspects of two-phase flow and two-phase heat transfer, where the primary eventual applications are the cooling of CPUs, power electronics, high energy physics particle detectors (CERN), micro-reactors, high power laser diodes, etc. This research is funded by Swiss FN, Nano-Tera, ESA, Eu, etc. projects as well as CTI, mandates and collaborations (IBM, ABB, Honeywell, etc.).

Below, an overview of this work is given, emphasizing the research relevant to electronics cooling.

Figure 2 shows some typical microchannel coolers having channel widths in the range of 50 µm to 200 µm and fin heights ranging from 50 µm to 2 mm. The copper fins were manufactured by a

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

29

On-chip cooling using micro-evaporators process called micro deformation technology (MDT), a patented process of Wolverine Tube Inc. [6], a long-time partner of the lab.

quite uniform. Interpreting these images and many others available in the lab, one ascertains that in small, horizontal channels that stratified types of flows (all vapor at top with liquid at the bottom) disappear. This transition is thus perhaps an indication of the lower boundary of macroscale two-phase flow, in this case occurring for a diameter somewhat greater than 2.0 mm. The upper boundary of microscale two-phase flow may be interpreted as the point in which the effect of gravity on the liquid-vapor interface shape becomes insignificant, such that the bubble in the 0.509 mm channel is thus a microscale flow, with the transition occurring at about this diameter at the present test conditions.

fig. 2 – examples of typical microchannel coolers in copper and silicon.

Similar fins can also be produced in aluminium, which is another common heat sink material. Such fins have been integrated into high performance micro-evaporators in collaboration with the LTCM lab. Also included is a silicon microchannel cooler having fin heights of 560 µm, fin width of 42 µm and a channel width of 85 µm. These channels were made by a process called deep reactive ion etching (DRIE) within a joint project with IBM. It is worth noting that what happens in small channels in twophase flows (evaporating refrigerant) is quite different than that for single-phase flows (water) in small channels. While initial studies in the literature reported significant size effects on friction factors and heat transfer cœfficients in very small channels in single-phase flows, more accurate recent tests and analysis done with very smooth internal channels have shown that macroscale methods for single-phase flows work well at least down to diameters of 5-10 µm. This is not the case for macroscale two-phase flow methods, which usually do not work very well when compared to data for channels below about 2.0 mm diameter. Thus, it is inappropriate to extrapolate macroscale research results and methods to the microscale. Furthermore, many of the controlling phenomena and heat transfer mechanisms change when passing from macroscale two-phase flow and heat transfer to the microscale. For example, surface tension (capillary) forces become much stronger as the channel size diminishes while gravitational forces are weakened. Therefore, it is not physically sensible to refit macroscale methods to microscale data since the underlying physics has substantially changed, and thus dedicated research is required to investigate these microscale two-phase flows and develop new models and methods to describe them.

As a first view, Figure 3 depicts the buoyancy effect on elongated bubbles flowing in 2.0, 0.790 and 0.509 mm horizontal channels.

In the 2.0 mm channel, the difference in liquid film thickness at the top compared to that at the bottom of the bubble is still quite noticeable (where this film thickness is the main resistance to heat transfer and thus cooling). Similarly, the film thickness in the 0.790 mm channel is still not uniform above and below the bubble. Instead, in the 0.509 mm channel, the film is now

30 flash informatique

fig. 3 – video images of slug (elongated bubble) flow in a 2.0, 0.8 and 0.5 mm horizontal channels with R-134a.

Heat transfer and pressure drop mechanisms are strongly affected by the type of flow patterns present in the channels, which need to be determined to develop prediction methods. With the aid of high-speed videography (videos up to 120’000 digital images per second) and laser photo diode signals, the LTCM was able to determine these regimes. Figure 4 shows a typical flow pattern map for R236fa inside a channel having a diameter of 1.03 mm. The flow patterns are identified as isolated bubbles (elongated bubbles), coalescing bubbles and annular flow (thin liquid film with vapor core).

On-chip cooling using micro-evaporators then repeats itself upon arrival of the next liquid slug at a frequency f (=1/τ). Thus, a liquid slug and an elongated bubble pair or a liquid slug, an elongated bubble and a vapor slug triplet pass this fixed point at a frequency f that is a function of the formation and coalescence rate of the bubbles upstream.

Lp Ll

Lv

R

dry zone

elongated bubble

δmin

liquid slug

δ0

d

q Ldry

fig. 4 – three flow regimes shown on a flow pattern map [7].

Lfilm (a)

Instant t 0

Jacobi and Thome [8] proposed the first theoretically-based, elongated bubble (slug) flow boiling model for microchannels, modelling the thin film evaporation of the liquid film trapped between these bubbles and the channel wall and also accounting for the liquid-phase convection in the liquid slugs between the bubbles.

The focus of their study was to demonstrate that the thin film evaporation mechanism was the principal heat transfer mechanism controlling heat transfer in slug flows in microchannels, not nucleate boiling as assumed by others in extrapolation of macroscale ideology to the microscale.

Figure 5 shows a representation of the three-zone model [9] of Thome et al. where Lp is the total length of the pair or triplet, LL is the length of the liquid slug, LG is the length of the bubble including the length of the dry wall of the vapor slug Ldry, and Lfilm is the length of the liquid film trapped by the bubble. The internal radius and the diameter of the tube are R and di while δo and δmin are the thicknesses of the liquid film trapped between the elongated bubble and the channel wall at its formation and at dry out of the film (only when dry out occurs). The evolution of successive bubbles is shown in the lower diagram. The local vapor quality, heat flux, microchannel internal diameter, mass flow rate and fluid physical properties at the local saturation pressure are input parameters to the model to predict the above parameters as well as the frequency of the bubbles, transient onset of local dryout, etc. The three-zone model predicts the local transient and timeaveraged heat transfer rate at a fixed location along a microchannel during evaporation of a succession of elongated bubbles (with frequencies of passage as high as 900 Hz). The elongated bubbles are assumed to nucleate and quickly grow to the channel size upstream such that successive elongated bubbles are formed that are confined by the channel and grow in axial length, trapping a thin film of liquid between the bubble and the inner tube wall as they flow along the channel. The thickness of this film plays an important role in heat transfer. At a fixed location, the process is assumed to proceed as follows: 1 a liquid slug passes, 2 an elongated bubble passes (whose liquid film is formed from liquid removed from the liquid slug) and 3 a vapor slug passes if the thin evaporating film of the bubble dries out before the arrival of the next liquid slug. The cycle

1

2

3

4

5

6

...

Instant t 0+τ 1

2

4

3

5

6

(b)

fig. 5 – three-zone heat transfer model of Thome et al. [9] for elongated bubble flow regime in microchannels. Top: Diagram illustrating a triplet comprised of a liquid slug, an elongated bubble and a vapor slug; bottom: Bubble tracking of a triplet with passage of a new bubble at time intervals of τ.

For high heat flux cooling applications using multi-microchannel cooling channels, the critical heat flux (CHF) in saturated flow boiling conditions is a very important operational limit. It signifies the maximum heat flux that can be dissipated at the particular operating conditions by the evaporating fluid. Surpassing CHF means that the heated wall becomes completely and irrevocably dry, and is associated with a very rapid and sharp increase in the wall temperature due to the replacement of liquid by vapor adjacent to the heat transfer surface.

Revellin and Thome [10] have proposed the first theoretically based model for predicting critical heat flux in microchannels.

Their model is based on the premise that CHF is reached when local dry out occurs during evaporation in annular flow at the location where the height of the interfacial waves matches that of the annular film’s mean thickness. To implement the model, they first solve one-dimensionally the conservation of mass, momentum and energy equations assuming annular flow to determine variation of the annular liquid film thickness δ along the channel.

Then, based on the slip ratio given by the velocities of the two phases (liquid and vapor) and a Kelvin-Helmoltz critical wavelength criterion (assuming the height of the waves scales proportional to the critical wavelength), the wave height was modelled with the following empirical expression:

=0.15

uG uL

3 7

g(

L

G

) (di 2)

1 2 7

.

Then, when d equals Dd at the outlet of the microchannel, CHF is reached. Refer to Figure 6 for a simulation. The leading constant and two exponents were determined with a database including three fluids (R-134a, R-245fa and R-113) and three circular chan-

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

31

On-chip cooling using micro-evaporators nel diameters (0.509 mm, 0.790 mm and 3.15 mm) taken from the LTCM CHF data of Wojtan et al. [11] and data from the Argonne Laboratory by Lazarek and Black [12]. Their model also satisfactorily predicted the Purdue R-113 data of Bowers and Mudawar [13] for circular multi-microchannels with diameters of 0.510 and 2.54 mm of 10 mm length. Furthermore, taking the channel width as the characteristic dimension to use as the diameter in their 1-d model, they were also able to predict the Purdue rectangular multi-microchannel data of Qu and Mudawar [14] for water.

All together, 90% of the database was predicted within ±20%.

As noted above, this model also accurately predicted the LTCM R-236fa multi-microchannel data of Agostini et al. [15]. Furthermore, this model also predicts CHF data of CO2 in microchannels from three additional independent studies as well as other fluids.

is pushed upstream by bubble growth downstream, the bubble gœs back into the inlet plenum in (b), as there is no restriction at the channel inlet of the channel to prevent this. This reversed bubble quickly moves to one of the adjacent channels, (c), and breaks down into smaller parts before entering these channels, (d). Depending on its location, the inserted bubble becomes stagnant, (e) and (f), before moving forwards or backwards again.

250

Radius [µm]

200

150

100

50

0 0

Wave height Film thickness 2

4

6

8 10 12 Heated length [mm]

14

16

18

20

fig. 6 – Revellin and Thome [10] CHF model showing the annular film thickness variation along the channel plotted versus the wave height.

Two-phase flow is much more complex than single-phase liquid flow and in this respect multi-microchannel flow boiling test sections can suffer from flow maldistribution, two-phase flow instabilities and even backflow effects. The flow may in fact flow back into the inlet header and some channels may become prematurely dry from too low of an inlet liquid flow rate.

fig. 7 – dramatic effect that maldistribution can have on the heat transfer process [16].

Figure 7 shows a sequence of video images to demonstrate back flow and parallel channel instability in multi-microchannel test section (something to be avoided). A slug bubble was observed at the inlet of the topmost channel in (a). If the flow in the channel

32 flash informatique

fig. 8 – flow boiling in a copper multi-microchannel test section from Park [16] showing the difference in bubble distribution a) without an inlet orifice and b) with an inlet orifice.

Using micro-inlet orifices can completely prevent backflow, flow instabilities and maldistribution. Figure 8a shows the maldistribution effect when no inlet orifice is used, with a large dry zone being visible in the top right corner. A critical heat flux of only 115W/cm2 was achieved. Figure 8b shows that maldistribution is avoided when making use of an inlet orifice, with heat fluxes in excess of 350W/cm2 being obtainable. This is equivalent to cooling of 35’000 100-Watt light bulbs per meter squared of surface area!

Hence, microscale flow boiling can dissipate very high heat fluxes!

The LTCM has thus proven that heat transfer characteristics of microchannels can be predicted successfully while also showing the capability microchannels have in removing high heat fluxes.

Numerous experimental campaigns on multi-microchannel evaporators have been performed by the LTCM. It was proven that, using a refrigerant evaporating at 60˚C (such as refrigerant R134a that is circulating in your climatisation

On-chip cooling using micro-evaporators system of your automobile), microprocessors could be kept well below their 85˚C limit, while removing heat fluxes in excess of 180W/cm2 or more [17]. Two-phase flow is also ideally suited for cooling of electronic hotspots (local heat fluxes on CPUs up to 400 W/cm2 or more) as heat transfer cœfficients (thermal resistances) naturally increase (decrease) over hotspot locations in the flow boiling process described earlier. This has the implications that electronics can have a more uniform temperature, implying that problems associated with adverse temperatures gradients are greatly diminished and hence higher clock speeds can be utilized.

The power requirements for removing the heat is also considerably lower than required for traditional air-cooling methods. This is due to the much larger heat carrying capacity refrigerants have over air, while also taking advantage of its latent heat, which is much higher than sensible heat of single-phase fluids. Savings of over 50% are achievable using this technology, with extra savings being possible if the energy gained from cooling the processors were to be used in a secondary process. This is shown in Figure 9.

Numerous other aspects of these microscale two-phase flows are under investigation in the LTCM lab, such as micro-PIV to characterize flow (with cavitation) through micro-orifices as small as 15-25 microns, transient aspects of the evaporation and bubble coalescence process, time-strip analysis of high speed videos to discern information on the dry out process and wave formation, flow pattern transition theory, etc.

[5]

[6] [7]

[8]

[9]

[10]

[11]

[12]

Data Center Power Supply, MW

70 60

Air cooling + IT Vapour compressor + IT Liquid pump + IT IT load

50 40

[13]

30 20

[14]

10 0 0

20

40 60 80 Energy Recovery Efficiency, %

100

[15]

fig. 9 – potential energy savings for a data center when using on-chip cooling with energy recovery compared to traditional air cooling.

References [1]

[2]

[3]

[4]

Koomy, J.G., Estimating Regional Power Consumption by Servers: A Technical Note. 2007, Lawrence Berkeley National Laboratory: Oakland, CA. Saini, M. and Webb, R.L., Heat Rejection Limits of Air Cooled Plane Fin Heat Sinks for Computer Cooling. IEEE Transactions on Components and Packaging Technologies, 2003.

26(1): p. 71-79.

Samadiani, E., Joshi, S. and Mistree, F., The Thermal Design of a Next Generation Data Center: A Conceptual Exposition. Journal of Electronic Packing, 2008.

130: p. 041104-1 - 041104-8.

Agostini, B., Fabbri, M., Park, J.E., Wojtan, L., Thome, J.R. and Michel, B., State-of-the-art of High Heat Flux Cooling Technologies. Heat Transfer Engineering, 2007. 28: p. 258-281.

[16]

[17]

Leonard, P.L. and Phillips, A.L. The Thermal Bus Opportunity – A Quantum Leap in Data Center Cooling Potential in ASHRAE Transactions. 2005. Denver, CO. Wolverine Tube Inc, www.wlv.com/markets/electronic-cooling.html. 2010.

Ong, C.L., Macro-to-Microchannel Transition in Two-phase flow and Evaporation, in Heat and Mass Transfer Laboratory (LTCM). 2010, École Polytechnique Fédérale de Lausanne: Lausanne.

Jacobi, A.M. and Thome, J.R., Heat transfer model for evaporation of elongated bubble flows in microchannels. Journal of Heat Transfer-Transactions of the Asme, 2002. 124(6): p. 1131-1136.

Thome, J.R., Dupont, V. and Jacobi, A.M., Heat transfer model for evaporation in microchannels. Part I: presentation of the model. International Journal of Heat and Mass Transfer, 2004. 47: p. 3375-3385.

Revellin, R. and Thome, J.R., An analytical model for the prediction of the critical heat flux in heated microchannels.

Int. J. Heat Mass Transfer, 2008. 51: p. 1216-1225.

Wojtan, L., Revellin, R. and Thome, J.R., Investigation of saturated critical heat flux in a single uniformly heated microchannel. Experimental Thermal and Fluid Science, 2006.

30: p. 765-774.

Lazarek, G.M. and Black, S.H., Evaporating Heat Transfer, Pressure Drop and Critical Heat Flux in a Small Vertical Tube with R-113. International Journal of Heat and Mass Transfer, 1982. 25(7): p. 945-960.

Bowers, M.B. and Mudawar, I., High flux boiling in low flow rate, low pressure drop mini-channel and micro-channel heat sinks. Int. J. Heat Mass Transfer, 1994. 37: p. 321332.

Qu, W. and Mudawar, I., Measurement and correlation of critical heat flux in two-phase micro-channel heat sink. Int. J. Heat Mass Transfer, 2004. 47: p. 2045-2059.

Agostini, B., Revellin, R., Thome, J.R., Fabbri, M., Michel, B., Calmi, D. and Kloter, U., High heat flux flow boiling in silicon multi-microchannels - Part III: Saturated critical heat flux of R236fa and two-phase pressure drops. International Journal of Heat and Mass Transfer, 2008. 51(21-22): p. 5426-5442.

Park, J.E., Critical Heat Flux in Multi-Microchannel Copper Elements with Low Pressure Refrigerants. 2008, École Polytechnique Fédérale de Lausanne.

Madhour, Y., Olivier, J.A., Costa-Patry, E., Paredes, S., Michel, B. and Thome, J.R., Flow Boiling of R134a in a Multi-Microchannel Heat Sink with Hotspot Heaters for Energy-Efficient Micrœlectronic CPU Cooling Applications.

IEEE Transactions on Components and Packaging Technologies, Accepted for publication, 2010. n

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

33

Analyse

Thermal-Aware Design for 3D Multi-Processors David.Atienza@epfl.ch, professor EPFL - Embedded Systems Laboratory

Une nouvelle conception des systèmes multiprocesseurs en 3D qui tient compte de leur comportement thermique est basée sur une vision système et une combinaison des approches hardware et logicielle.

New Thermal-Aware 3D Multi-Processor Design with Liquid Cooling for Energy-Efficient HPC systems.

Abstract New tendencies envisage 3D Multi-Processor System-On-Chip (MPSoC) design as a promising solution to keep increasing the performance of next-generation high-performance computing (HPC) systems. However, as the power density of HPC systems increases with the forthcoming arrival of 3D MPSoCs, supplying electrical power to the computing equipment and constantly removing the generated heat is rapidly becoming the dominant cost in any HPC facility. Thus, both power and thermal/cooling implications are gradually becoming a major concern for the design of new HPC systems, given the current energy constraints in our society. Moreover, the placement of computational units and storage components on top of each other in HPC systems can lead to degraded performance and even malfunctioning if thermalaware design and thermal management are not properly handled at the different levels of system integration.

Therefore, the Embedded Systems Laboratory (ESL) of EPFL has been working on the development of novel thermal-aware design paradigms for 3D-MPSoCs in the last three years, in cooperation with the Microelectronics Systems Laboratory (LSM), the Laboratory of Heat and Mass Transfer (LTCM) of EPFL, IBM, ETHZ and ST Microelectronics within the CMOSAIC Nano-Tera.ch program and the PRO3D EU FP7 project. The goal of the work developed at ESL in this framework is the exploration of the thermal modeling and system-level design methods that are necessary to develop 3D MPSoCs with inter-tier liquid cooling systems, as well as the deployment of the energy-efficient run-time thermal control strategies to achieve energy-efficient cooling mechanisms to compress almost 1 Tera nano-sized functional units into one cubic centimeter with a 10 to 100 fold higher connectivity than otherwise possible. Therefore, the proposed thermal-aware design paradigm includes exploring the synergies of hardware-, software- and mechanical-based thermal control techniques as fundamental step to design 3D MPSoCs for HPC systems. This paradigm includes the use of inter-tier coolants ranging from liquid water and twophase to novel engineered environmentally friendly nano-fluids, as well as using specifically designed micro-channel arrange-

flash informatique

ments, in combination with the use of dynamic thermal management at system-level to tune the flow rate of the coolant in each microchannel to achieve thermally-balanced 3D-ICs.

Introduction The power density of high performance systems continues to increase with every process technology generation. Hence, it is not possible to design the next-generation of supercomputers using the existing solutions for high-performance computing (HPC) systems. As the density of supercomputers increases with the arrival of chip multi-core and multi-threaded processors, supplying electrical power to the computing equipment and constantly removing the generated heat is rapidly becoming the dominant cost in any HPC facility, even further than the new server deployment costs (see Figure 1). Thus, both power and thermal/cooling implications are increasingly playing a major role in the design of new HPC systems, especially given the current energy constraints in our society.

Spending (US$B)

■ New server spending ■ Power and cooling ▲ Installed base (M units)

$90 $80

▲

$70 U.S. Market

$60

$30

▲

$20

$ 0

▲ 1996

▲

▲

▲

▲

14

10

▲

$40

16

12

▲

$50

$10

▲

18 ▲

▲

8 6

▲

4 2

1998

2000

2002

2004

2006

2008

0

fig 1 – projections of energy cost expenditure in new HPC deployment equipment and maintenance costs (power and cooling) in the US market

In addition, 3D integration (i.e., multiple layers of processor, memories, etc. in the same chip stack) is a recently proposed design method for overcoming the limitations with respect to delay, bandwidth, and power consumption of the interconnects in large MPSoC chips, while reducing the chip footprint and improving the fabrication yield. However, one of the main challenges for designing 3D circuits is the elevated temperatures resulting from higher thermal resistivity, which irregularly spread in the whole 3D chip stack, as shown in the 3D 50-core thermal test stacks based on the Niagara Sun SPARC architecture developed within CMOSAIC (see Figure 2). As Figure 2 shows, it is more difficult to remove the heat from 3D systems with respect to conventional 2D MPSoCs. Moreover, 3D MPSoCs are also prone to larger thermal variations.

For instance, cores located at different tiers or at different coor-

Thermal-Aware Design for 3D Multi-Processor dinates across a tier have significantly different heating/cooling rates. Such large thermal gradients have very adverse effects on system reliability, performance, and overall cooling costs of large HPC systems. Therefore, temperature-induced problems exacerbate in 3D stacking and are a major concern to be addressed and managed as early as possible in 3D MPSoC design. Furthermore, alternative cooling techniques must be developed for future 3Dbased HPC systems.

address the high temperatures in 3D MPSoCs, due to the higher heat removal capability of liquids in comparison to air. This technology being developed by the CMOSAIC Nano-Tera.ch RTD project, as shown in Figure 3(a)(b), involves injecting water through micro-channels between the tiers of a 3D stack. This cooling technology scales with the number of dies and it is compatible with area-array vertical interconnects (through silicon vias or TSVs), which are needed to connect the different electrical components in the 3D processing architectures.

fig 3 (a) – detail of the microchannels and TSVs in the 3D stack chip

fig. 2 (a) – manufactured 5-tier stack chip at EPFL for 3D MPSoC thermal calibration and

fig 3 (b) – 3D stacked MPSoC with inter-tier liquid cooling

fig. 2(b) – transient thermal map (in K) of the Sun-based 50-core MPSoC emulated system with only 10 cores being active

Thermal Modeling of 3D MPSoCs with Liquid Cooling Conventional back-side heat removal strategies, such as, air cooled heat sinks and microchannel cold-plates only scale with the die size and are insufficient to cool 3D MPSoC with hotspot heat fluxes up to 250W/cm2, as forthcoming 3D MPSoC stacks.

On the contrary, inter-tier liquid cooling is a potential solution to

fig 3 (c) – SEM micrograph showing the TSV structures

A magnified image of the TSV structures is shown in Figure 3(c).

The use of such complex cooling technologies necessitates the development of a fast thermal modeling platform to enable cooling-aware design of 3D MPSoCs during the early design-stages. In fact, accurate thermal models are needed for predicting the costs of operating the liquid cooling (pumping power) in HPC systems, determining the overall energy budget and performing run-time thermal management. However, it is impractical to use extremely detailed simulation methods to analyze thermal effects and model

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

35

Thermal-Aware Design for 3D Multi-Processor temperature distribution in the target 3D MPSoC designs. Figure 4 shows layouts of these 3D MPSoCs targeted with this liquid cooling technology. They consist of two or more stacked tiers (with cores, L2 caches, crossbar, memory control units, etc.), and water microchannels are distributed uniformly in between these tiers.

fig. 5 (a) – 3D stacked MPSoC architecture with interlayer microchannel cooling;,

fig. 4 – Sun-SPARC 3D MPSoCs layouts with inter-tier liquid cooling

Then, Figure 5 shows a detailed inter-tier cooling internal structure of these new 3D MPSoCs, as well as the 5-tier 3D IC test structures with liquid cooling developed in CMOSAIC. Indeed, using detailed numerical analysis methods, such as finiteelement methods (FEM). FEM-based thermal and cooling exploration is a time-consuming process not suitable for design-time and run-time thermal management of such complex 3D MPSoCs, and we use multi-scale modeling concepts at system-level thermal modeling to improve computational efficiency of cooling requirements. Hence, at ESL we have developed 3D-ICE [1] (or 3D Interlayer Cooling Emulator), which is a compact transient thermal model library (written in C) for the thermal simulation of 3D ICs with multiple inter-tier liquid cooling microchannels. 3D-ICE is compatible with existing CAD tools for MPSoC designs, and offers significant speed-ups (up to 975x) over typical commercial computational fluid dynamics and thermal simulation tools while preserving accuracy (i.e., maximum temperature error of 3.4%) for 3D MPSoCs.

fig. 5 (b) – a 3D IC test vehicle with lateral wire-bonds for electrical IO and fabricated with fluid manifold mounted on a printed circuit board;

System-Level Thermal Management of 3D MPSoCs Even if inter-tier liquid cooling is a potentially effective cooling technology for future 3D MPSoCs, due to the limited diameter of the inter-tier microchannels (channel width and thickness of less than 100µm and 50µm, respectively), the energy spent in the pump that injects the coolant can be very significant. In fact, in an HPC cluster, a central pump, such as a centrifugal pump (e.g., EMB MHIE), is responsible for the fluid injection to a cluster of nodes. This pump has the capability of producing large discharge rates at small pressure heads. Then, liquid is injected to the stacks from this pump via a pumping network. To enable different flow rates for each stack, the cooling infrastructure includes valves in the network, such closed (NCV) valves. NCVs use external power to reduce the pressure drop and to increase the flow rate.

36 flash informatique

fig. 5 (c) – detail of the wire bonding process

Cooling power consumption per stack (Watts)

Figure 6 shows the pump and valve power consumption for three flow rate settings of a single stack deployed in a cluster with 60 similar 3D MPSoC stacks, as proposed in the Aquasar IBM datacenter design. The maximum energy required to inject the fluid to all stacks is a significant overhead to the whole system, because it represents about 70 Watts (indeed similar to the overall energy consumption of a 2-tier 3D MPSoC). Hence, it is necessary to minimize at system-level the required cooling energy in the liquid injection architecture to achieve energy-efficient cooling infrastructures for 3D MPSoC-based HPC systems.

12

■ Valve ■ Pump

10 8 6 4 2 0

0.01

0.02

0.0323

Flow rate per stack (L/min)

fig. 6 – power consumption and flow rates of the cooling infrastructure per one stack in a 60 3D-chips cluster

Therefore, based on 3D-ICE, ESL has recently developed a new family of global hardware-software temperature controllers (Active-Adapt3D Thermal Controllers [2][3]) for energy-efficient 3D MPSoC cooling management. As Figure 7 shows, these controllers include a thermal-aware job scheduler, which distributes the weighted (from a temperature increase viewpoint) workload and tasks between the multiple cores of each tier to balance the global temperature across the 3D system in order to maximize cooling efficiency. Then, they forecast maximum system temperature based on Auto-Regressive Moving Average (ARMA) models and proactively set the liquid flow rate using the pump controller.

Monitor Temperature Forecast Maximum Temperature (ARMA)

SCHEDULER: Temperature-Aware (Weighted) Load Balancing

% hot spots (>85 C)

Thermal-Aware Design for 3D Multi-Processor 100

■ % hot spots avg (per core) ■ % hot spots avg (system) ■ % hot spots Web-high (per core) ■ % hot spots Web-high (system)

80 60 40 20 0 AC_LB

AC_TTMig

AC_TDVFS AC_TTMig_TDVFS

LC_LB

LC_Fuzzy

fig. 8 – percentage of time of hot-spots per core and across the entire die for 4-tier 3D MPSoC designs running different system-level thermal control policies (i.e., average case across all workloads and for Web-high, the hottest workload benchmark set)

Conclusions Microchannel-based liquid cooling is a promising cooling technology solution to overcome the thermal challenges of 3D MPSoCs in HPC architectures. However, intelligent control of the coolant flow rate is needed to avoid wasted energy consumption for over-cooling the system when the system is under-utilized.

Therefore, ESL and its research partners are working on the development of novel system-level thermal-aware design methodologies, as an effective and combined (mechanical-electrical) technology approach to achieve thermally-balanced 3D MPSoCs for HPC systems.

Acknowledgements The author wants to thank Prof. Ayse K. Coskun (Boston Univ.), Prof. Yusuf Leblebici (LSM), Thomas Brunschwiler and Dr Bruno Michel (Advanced Packaging Group – IBM Zürich), and the ESL members for their contributions to this work. This research is partially funded by the Nano-Tera RTD project CMOSAIC (ref.123618), financed by the Swiss Confederation and scientifically evaluated

by SNSF, the PRO3D EU FP7-ICT-248776 project, and a grant donation of the OpenSPARC University Program of Sun Microsystems-ORACLE for ESL.

References

Change in Maximum Temperature?

NO

YES

3D MPSoC

CONTROLLER: Flow Rate Adjustment

fig. 7 – architecture of the Active-Adapt3D Thermal Controllers for 3D MPSoC architectures

As illustrated in Figure 8, the latest experiments on 4-layered 3D MPSoCs (cf. Figure 4), indicate that this new generation of 3D thermal management and cooling controllers, i.e., a liquid cooling controller based on fuzzy logic (LC_fuzzy) or targeting global load balancing (LC_LB), prevent the system to exceed the given threshold temperature (90ºC) while reducing cooling energy by up to 50% with respect to a worst-case flow rate setting. Also, they improve system-level energy by up to 21% with respect to stateof-the-art temperature controllers for MPSoC architectures using air cooling, i.e., dynamic load balancing (AC_LB), temperaturetriggered task migration (AC_TTMig) or temperature-triggered dynamic frequency and voltage scaling (AC_TDVFS).

[1] 3D-ICE: Fast compact transient thermal modeling for 3DICs with inter-tier liquid cooling, Arvind Sridhar, Alessandro Vincenzi, Martino Ruggiero, David Atienza, Thomas Brunschwiler, Proc. of International Conference on Computer-Aided Design (ICCAD), San Jose, CA, USA, ACM and IEEE Press, ISBN: 978 1-4244-8192 7/10, pp. 463-470, November 7-11 2010. Simulator available for download at: esl.epfl.ch/3dice.html.

[2] Fuzzy Control for Enforcing Energy Efficiency in High-Performance 3D Systems, Mohamed Sabry, Ayse K. Coskun, David Atienza, Proc. of International Conference on Computer-Aided Design (ICCAD), San Jose, CA, USA, ACM and IEEE Press, ISBN: 978 1-4244-8192 7/10, pp. 642-648, November 7-11 2010.

[3] Energy-Efficient Variable-Flow Liquid Cooling in 3D Stacked Architectures, Ayse K. Coskun, David Atienza, Tajana Simunic, Thomas Brunschwiler, Bruno Michel, Proc. of Design, Automation and Test in Europe (DATE '10), Dresden, France, ACM and IEEE Press, ISSN: 1530-1591/05, ISBN: 9783-9810801-6-2, pp. 1 - 6, 8-12 March 2010. n

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

37

Actualités

HPC: l'énergivore Aristide.Boisseau@epfl.ch, EPFL – Domaine IT

Feedback from the 2nd HPC infrastructures workshop.

Retour sur le 2e workshop sur les infrastructures HPC. Après le premier workshop de 2009 qui s’est déroulé au CSCS (voir article du FI8/2009: Défis techniques pour les centres de calcul) la deuxième édition a eu lieu début octobre à Dourdan (au sud de Paris) à proximité du site militaire du CEA de Bruyèresle-Châtel. Le CEA a organisé deux jours de conférences et huit sessions avec des intervenants de différents domaines tels que des constructeurs IT (CRAY, Intel, HP, IBM… ) et des utilisateurs de différentes universités/organismes gouvernementaux (Riken au Japon, CSCS &, CEA &, LRZ &, ORNL&, NCSA &). Ces derniers ont présenté leurs projets en cours ou à venir et les défis qui se profilent pour la prochaine décennie. Cet article résume ces deux jours de workshop [1] qui ont abordé plus particulièrement la problématique des infrastructures des centres de calcul hébergeant des ressources HPC supérieures à plusieurs MW.

Une bonne mise en valeur également du PUE est montré sur la figure 2, plus le PUE est petit plus l’efficacité est grande: si on dispose d’un MW avec un PUE de 1.25 alors 80% pourront être dédiés pour le calcul alors qu’avec un PUE de 2 on tombe à 50%.

impact du PUE 50

40

30

20

10

2 1.67 1.43 1.25 1.11 puissance liée au calcul ■, à l’infrastructure ■

fig. 2 – PUE et répartition de la puissance

Évolution des coûts

La maîtrise de l’énergie Pour faire fonctionner ces Formule 1 du FLOPS & il faut évidemment de la puissance électrique, non seulement pour alimenter la machine elle-même, mais aussi pour la refroidir. Dans ce domaine nous parlons de plusieurs MW voire des dizaines de MW. Le coût d’exploitation de ces infrastructures représente une part non négligeable dans le TCO & de ces mastodontes du calcul.

Prenons comme exemple le projet Jaguar hébergé à l’ORNL qui délivre 2.33 pétaFLOPS pour une consommation électrique de 7 MWh. Prenons un KWh à 15cts et calculons le coût annuel des besoins en électricité: 0,15x7000x24x365 = 9,2 millions de CHF. 18.2 17.2 16.2 15.2 14.2 13.2 12.2 11.2 10.2 9.2

Millions de CHF/an

17.5

18.4

16.6 15.6 14.7 13.8 12.9 12.0 11.0 10.1 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

2

PUE

fig. 1 – PUE et coût

À ce coût il faut rajouter le coût énergétique pour le refroidissement qui est fonction du PUE &. Le PUE avancé par l’ORNL est de 1.25, d’où le coût annuel de 11,5 millions de CHF. Évidemment plus le PUE sera petit plus l’économie sera importante. La figure 1 montre l’importance de la maîtrise du PUE sur la facture énergétique.

flash informatique

fig. 3 – tarif MWh

L’évolution des coûts de l’énergie est aussi un point important dans le TCO des centres de calculs. La Figure 3 montre l’évolution du coût du MWh en Suisse sur trois années (2007-2009). Difficile alors de faire des projections du tarif du MWh sur les prochaines années. Le coût d’achat d’un super calculateur est généralement connu une fois le contrat d’achat signé, il n’en va pas de même pour le calcul de son TCO qui inclut tous les autres frais de fonctionnement dont la facture énergétique.

La mise en place de génératrices de cogénération ou de trigénération présentée par la société MTU [2] peut être un atout pour pérenniser la gestion de l’énergie. La production d’énergie est optimisée sur ces nouvelles technologies, MTU annonce une efficacité électrique de 49% ( 90% si on optimise les énergies thermiques et électriques), valeur supérieure aux autres technologies dans ce domaine (micro turbine, génératrice au gaz).

HPC: l’énergivore La trigénération génère à partir d’une énergie primaire (du gaz en règle général) trois énergies utilisables: électrique, thermique (chauffage industriel par exemple) et production de froid.

Ce qui est tout à fait adapté aux besoins des centres de calcul, on peut citer en particulier l’exemple concret l’hôpital de Bad Berka (RFA) qui utilise la chaleur générée pour la stérilisation, le froid généré pour les salles d’opérations et évidemment l’électricité.

Les nouvelles infrastructures Différents projets ont été présentés à Dourdan notamment une visite in vivo du futur site du CEA où sera hébergé le futur Tera100 pouvant délivrer 1.25 pétaFLOPS. Toutes ces nouvelles infrastructures utilisent l’eau comme composant essentiel de refroidissement, beaucoup plus efficace que l’air. L’eau est utilisée dans les racks pour le refroidissement des machines, comme présenté dans l’article déjà cité de l’année passée: Défis techniques pour les centres de calcul.

Le PUE est fixé dans le cahier des charges, il est donc un objectif à atteindre. Les nouveaux centres de calculs sont donc des centres de mesures pour établir la meilleure gestion de l’énergie possible.

Pour diminuer le TCO d’une infrastructure et également son PUE, la politique de redondance doit être soigneusement étudiée. Dans le domaine HPC les nœuds (CPU/cores) de calculs représentent souvent 80% de la puissance totale de la machine. Ces nœuds n’ont pas besoin d’être sur du courant secouru, autant d’économies réalisées lors de la mise en place de l’infrastructure: pas d’UPS&, pas de batteries, pas de génératrice à installer pour cette partie importante de la puissance d’une machine HPC. Vu les TCO des infrastructures, tous les moyens sont bons pour faire baisser le PUE, l’utilisation du free cooling est privilégiée selon les ressources à disposition (air froid, eau…). Le CSCS à Manno va puiser l’eau dans le lac de Lugano, l’EPFL dans le lac Léman.

L’utilisation de la géothermie est évoquée dans la mise en place du futur centre de calcul PAWSEY à Perth en Australie (objectif 1 pétaFLOPS pour 2013) [3]. En effet l’air ambiant et l’eau salée ne font pas une alliance idéale avec le free cooling dans le sudouest de l’Australie. Au centre de recherche de Riken au Japon des génératrices de cogénération sont utilisées pour la génération du courant et du refroidissement de l’eau (objectif 10 pétaFLOPS en 2012), le solaire est également utilisé pour accentuer l’effort mis sur l’utilisation des énergies renouvelables.

Pour éviter les transformations successives de courant donc les pertes, pour améliorer le PUE, on peut privilégier des équipements en 400V plutôt qu’en 220V par exemple. Ce choix fait partie des décisions concernant les nouvelles infrastructures du CSCS à Manno.

L’avenir

une faible émission de CO2. Les composants les plus énergivores sont directement refroidis à l’eau, au plus proche du composant.

Le système peut être refroidi avec de l’eau à 60°C, l’eau en sortie est à 65° et utilisable pour des besoins industriels (chauffage, …); voir vidéo expliquant les principes du projet [5]. La suite logique du refroidissement serait de se diriger vers des fluides plus efficaces pour les échanges thermiques que l’eau, pour le moment aucun constructeur n’a évoqué cette option. C’est sans doute encore du domaine de la R&D et de la confidentialité chez les constructeurs, car aucun n’en a parlé (IBM, CRAY, Intel, HP). Dans ce numéro, l’article On-chip cooling using micro-evaporators du laboratoire de transfert de chaleur et de masse peut montrer une direction possible dans ce sens.

Go to exaFLOPS Sans nul doute la prochaine barrière à atteindre sera la barre de l’exaFLOPS: soit environ 500 Jaguars décrits plus haut dans cet article. Si on extrapole de manière linéaire en terme de puissance la machine demanderait 3.5 GW (sans compter l’infrastructure de refroidissement et le facteur PUE) ! Une belle centrale électrique en perspective. En terme de surface au sol il faudrait 23 hectares environ pour poser les racks. Avec ses valeurs cette future machine ne risque pas de voir le jour. Néanmoins, un des objectifs de l’ORNL est un HPC exaFLOPS avant la fin de la décennie pour une consommation électrique dans une fourchette de 50 à 100MW voire moins.

Ceci implique de facto que le nombre de FLOPS par watt doit croître fortement par exemple ! Reste à savoir si les constructeurs pourront tenir cette croissance. En tout cas la course est lancée depuis longtemps, l’Empire du Milieu vient de détrôner l’Oncle Sam de sa place de numéro un du HPC .

Références [1] programme complet du workshop: www-hpc.cea.fr/en/events/ Workshop-HPC-2010.htm; [2] www.mtu-online.com/mtuonsiteenergy/products/fuel-cell-systems; [3] www.ivec.org/pawsey/index.html; [4] www.green500.org [5] www-03.ibm.com/press/us/en/pressrelease/27816.wss. n GLOSSAIRE

&

CEA: Commissariat à l’Energie Atomique CSCS: Swiss National Supercomputing center FLOPS (FLoating point Operations Per Second): nombre d’opérations à virgule flottante par seconde.

LRZ: Leibniz-Rechen Zentrum.

Les constructeurs annoncent un refroidissement de plus en plus proche des points des sources de chaleur: c’est-à-dire directement sur les cartes et les chips (CPU/Core/Mémoire…).

Le projet QPACE d’IBM est un premier pas dans ce sens, de plus il est sur la première marche de la Green 500 list [4]. IBM a présenté également son projet AQUASAR qui est mis en place à l’ETHZ. Le but de ce projet est d’avoir une valeur élevée de mégaFLOPS/W et

NCSA: National Center for Supercomputing Applications.

ORNL: Oak Ridge National Laboratory.

PUE (Power Usage Effectiveness): nombre sans unité qui représente le rapport de la puissance électrique totale nécessaire au centre de calcul divisé par la puissance électrique consommée par les matériels informatiques.

TCO (Total Cost of Ownership): coût total de possession.

UPS (Uninterruptible Power Supply): alimentation secourue.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

39

Actualités

GPU Technology Conference 2010 Francis.Lapique@epfl.ch, EPFL - Domaine IT

The NVIDIA GPU Technology conference is a meeting point for developers, engineers and researchers using the computing power of graphic cards (GPUs) to be up to the newest challenges in scientific computing. Jen-Hsun Huang, CEO and co-founder of NVIDIA, Klaus Schulten, one of the pioneers of bioinformatics at Illinois University at Urbana-Champaign and Sebastian Thrun, a researcher in robotics Standford University and Google engineer hosted the three keynotes of this 2010 edition.

La GPU Technology Conference de NVIDIA est un espace de rencontre pour les développeurs, ingénieurs et chercheurs qui utilisent la puissance des processeurs graphiques (GPU) pour résoudre les défis de calcul les plus critiques. Jen-Hsun Huang CEO et cofondateur de NVIDIA, Klaus Schulten de l'Université de l'Illinois à Urbana-Champaign, un pionnier dans le domaine de la bio-informatique et Sebastian Thrun, un chercheur en robotique travaillant à l'université de Stanford et ingénieur chez Google ont animé les trois Keynotes de ce cru 2010.

La deuxième GTC (GPU Technology Conference 2010) s’est tenue à San José les 20-23 septembre derniers. GTC est un évènement organisé par NVIDIA pour promouvoir le domaine GPGPU &. Pour cette seconde édition, NVIDIA avait résolument ciblé un vaste écosystème du monde académique travaillant dans le domaine du calcul haute performance.

Quelques titres de présentations pour illustrer la tendance 2010: z Modified Smith-Waterman-Gotoh Algorithm for CUDA Implementation (The Johns Hopkins University); z Towards Peta-Scale Green Computation - Applications of the GPU Supercomputers in the Chinese Academy of Sciences (CAS); z CUDA for Real-Time Multigrid Finite Element Simulation of Soft Tissue Deformations (Technische Universität München); z GPU-Based Conjugate Gradient Solvers for Lattice QCD (National Taiwan University).

Les moments-clés de ces GTC sont les keynotes très attendus par les participants et la presse des milieux économiques et techniques. C’est Jen-Hsun Huang, CEO et co-fondateur de NVIDIA qui se présente sur la scène pour lancer GTC-2010. Le keynote commence par une phrase-choc: Desperately Need Approach Based on Parallelism qui s’accompagne d’une équation: New CW is Power Wall + Memory Wall + ILP Wall = Brick Wall

L’ensemble est tiré d’un article de David A. Patterson (2007): Computer Architecture is Back - The Berkeley View on the Parallel Computing Landscape (D. Paterson est le co-auteur du célèbre livre Computer Architecture: A Quantitative Approach 1). Par CW il faut entendre Conventional Wisdom in Computer Architecture. L’équation est le point 9 d’une liste qui en compte 12.

Nous reproduisons dans le tableau ci-contre la version originale de cette liste de 12 points qui garde toute sa pertinence.

Patterson note un gain de performance de 25% par année pour la période 1978-1986 (VAX) et de 52% par année pour la période 1986-2002 (x86). Depuis 2002, la courbe s’infléchit. Conclusion: si on garde les mêmes approches d’architectures, c’est un écart de 100 en termes de performance qui sera perdu en 2021 avec la projection de la courbe 1986-2002.

Le show se poursuit avec des images 3D de Endless City: 1.3 milliard de polygones par seconde avec un rendu de plus de 1000 sources lumineuses. Puis quelques annonces: CUDA x86: un nouveau compilateur CUDA développé par PGI qui permettra d’exécuter du code CUDA sur l’architecture Intel moyennant des performances logiquement moindres. Il sera possible d’exécuter sur son processeur, Intel ou AMD, un programme conçu à la base pour le processeur graphique.

Matlab bénéficiera de l’accélération matérielle offerte par les cartes graphiques de génération Fermi à travers un nouveau produit Cuda Accelerated Parallel Programming Toolbox. Le gain de performance entre cluster GPU et son homologue CPU peut être de l’ordre de 40x.

Le logiciel Amber (Assisted Model Building and Energy Refinement) dans sa version 11, logiciel qui a pour but de comprendre le repliement et l’agrégation des protéines et les maladies qui y sont liées, a été benchmarké. Le JAC (Joint Amber-Charmm) benchmark a montré qu’avec 192 processeurs quadri-cœurs du superordinateur Kraken (Oak Ridge National

Computer Architecture: A Quantitative Approach, David A. Patterson et John L. Hennessy

1

flash informatique

GPU Technology Conference 2010 Old Conventional Wisdom

New Conventional Wisdom

1

Power is free, but transistors expensive.

is the Power wall: Power is expensive, but transistors are free. Can put more transistors on a chip than have the power to turn on.

2

Only concern is dynamic power.

For desktops and servers, static power due to leakage is 40% of total power.

3

Monolithic uniprocessors are reliable internally, with As chips drop below 65 nm feature sizes, they will have high soft and errors occurring only at pins. hard error rates.

4

By building upon prior successes, continue raising level Wire delay, noise, cross coupling, reliability, clock jitter, design validaof abstraction and size of HW designs. tion, … stretch development time and cost of large designs at ≤ 65 nm.

5

Researchers demonstrate new architectures by building Cost of 65 nm masks, cost of ECAD &, and design time for GHz clocks chips. ⇒ Researchers no longer build believable chips.

6

Performance improves latency & bandwidth.

Bandwidth improvevements > (latency improvements).

7

Multiplies are slow, but loads and stores are fast.

is the Memory wall: loads and stores are slow, but multiplies fast.

Memory transferts cost 200 clock cycles while FP & multiplies just 4.

8

We can reveal more ILP & via compilers and architec- is the ILP wall: Diminishing returns on finding more ILP. ture innovation. Branch prediction, OOO execution, speculation, VLIW, …

9

2X CPU Performance every 18 months.

is Power Wall + Memory Wall + ILP Wall = Brick Wall.

10 Increasing clock frequency is primary method of perfor- Processors Parallelism is primary method of performance improvement. mance improvement.

11 Don’t bother parallelizing app, just wait and run on No one building 1 processor per chip. much faster sequential computer.

End of La-Z-Boy Programming Era. 12 Less than linear scaling for a multiprocessor is failure.

Given the switch to parallel hardware, even sublinear speedups are beneficial.

Laboratory) qui compte 8256 nœuds, on obtient un résultat de 46ns de simulation par jour de calcul quand huit GPU Fermi effectuent la même simulation à 52ns par jour.

La feuille de route pour les prochaines cartes graphiques a été dévoilée: 1. nom de code: Kepler, prochaine architecture graphique prévue pour le second semestre 2011, sur une base 28nm.

Kepler offrirait des performances par Watt 3 à 4 fois supérieures à la génération actuelle; 2. en 2013, nom de code: Maxwell, une nouvelle architecture sur une technologie 22nm qui offrirait des performances par Watt 16 fois supérieures à l’architecture Tesla qui équipait les GeForce GTX de la série 200, 10 à 12 fois supérieure à l’architecture Fermi.

Tegra: depuis quelques années, NVIDIA développe un Systemon-a-chip qui regroupe sur un même morceau de silicium un cœur d’exécution ARM, un module de gestion des entrées/sorties et un cœur graphique. Tegra est destiné aux téléphones portables, consoles portables, tablettes. C’est plaisant du point de vue du concept, mais aujourd’hui fort peu de produits utilisent Tegra. Malgré ce contexte difficile, NVIDIA annonce que la troisième génération de produits Tegra était prête et que les ingénieurs de NVIDIA travaillent déjà sur Tegra 4.

La vision NVIDIA: des super smartphones, tablettes et netbooks se connecteront directement au cloud.

Adobe Plenoptic Lens: présentation d’un produit qui pourrait bien révolutionner la photographie à en croire Adobe: transformer n’importe quelle photo floue en une photo nette. En effet, en disposant d’un appareil photo dit plénoptique & et d’un algorithme proposé par Adobe (exécuté sur une carte

NVIDIA) vous pouvez changer la mise au point d’une photo, c'est-à-dire de modifier, a posteriori, le focus d’une photo.

Nebulae (CPU Intel X5650 et GPU NVidia Tesla C2050), un cluster pétaflopique chinois (Linpack 1.271 pétaFLOPS) qui a fait une entrée remarquable dans le top 500 des machines les plus rapides de la planète en se classant en deuxième position en juin 2010.

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

41

GPU Technology Conference 2010

Dans ce contexte Dale Southard, senior hardware architect chez NVDIA, nous a présenté un exposé intéressant ayant pour titre Lessons Learned Deploying the World’s First GPUBased PetaFLOP System, destiné à un public qui voudrait se lancer dans ce genre d’aventure. Dale Southard a participé à l’installation (qui a pris 90 jours) de Nebulae. Il nous fait part de quelques évènements qui se produisent lors de l’assemblage d’un système qui dépasse le millier de nœuds. Il faut être pro-actif sur les tests avant l’assemblage: niveau du BIOS, vitesse processeurs, tout peut arriver au niveau hardware comme de minuscules capacités qui explosent comme de petites grenades et endommagent les composants alentour.

Depuis la conférence, en octobre 2010, Tianhe-1A un nouvel ordinateur chinois basé aussi sur des GPU a atteint les 2.566 pétaFLOPS ce qui lui a permis de se positionner en première place des Top 500. Il ne consomme que 4MW, contre 12 MW estimés pour l'équivalent en processeurs classiques. En guise de conclusion Oracle va-t-il s’offrir AMD ou NVIDIA? Le 27 septembre 2010, les journaux rapportent ces propos d’Ellison lors de la présentation annuelle d’Oracle à San Francisco: «Vous allez nous voir acheter des constructeurs de processeurs». La société a déjà racheté officiellement cette année Sun Microsystems pour 7,4 milliards de dollars et elle dispose encore d’environ 23 milliards de dollars de trésor de guerre. n

GLOSSAIRE

&

ECAD (Electronic Design Automation): conception assistée par ordinateur pour l'électronique.

FP (floating point): virgule flottante.

GPGPU (General-Purpose computation on Graphics Processing Units): calcul générique sur un processeur graphique.

ILP (Instruction Level Parallelism). plénoptique: c’est-à-dire composé d’une lentille composée ellemême de plusieurs dizaines de mini-lentilles avant le capteur CCD. W W = tiré de Wikipédia

42 flash informatique

Actualités

Échos de la con Jean-Claude.Berney@epfl.ch, EPFL – Directeur du Domaine IT

Exascale computing and energy efficiency were among the most important subjects debated during the SC10 supercomputing conference in New Orleans. New systems were presented that will set a new FLOPS/Watt Standard Performance.

Le calcul Exascale et les problèmes de consommation d'énergie électrique étaient à l'ordre du jour de la dernière conférence SC10 sur le supercomputing à la Nouvelle Orléans. De nouvelles solutions présentées vont définir de nouveaux standards en ce qui concerne la puissance de calcul par Watt.

La plus grande rencontre annuelle sur le sujet du SuperComputing a eu lieu cette année du 13 au 19 novembre 2010 à la Nouvelle Orléans (voir le site officiel www.sc10.org). Elle s’est déroulée dans le Ernest N. Morial Convention Center et a battu tous les records de participation (4'390 personnes pour les programmes techniques et plus de 10’000 au total). Ce Convention Center est le 2ème de tous les USA sur le plan de l’activité et le 5ème en taille.

On a l’impression qu’il fait vivre tout le centre-ville de la Nouvelle Orléans (en particulier le quartier français avec la fameuse Bourbon Street). D’ailleurs, en même temps que se déroulait SC10, avait lieu dans le même Convention Center une conférence dans le domaine de la pharmacie (PSWC 2010) avec également plus de 10’000 participants.

L’annonce faite par les Chinois du superordinateur le plus puissant au monde (www.top500.org/) quelques jours avant l’ouverture de la conférence SC10 a quelque peu plombé l’ambiance, car il faut bien le reconnaître, le domaine est habituellement dominé par les Américains avec leurs grands centres de supercomputing soutenus par le Département de la Défense. Même s’il s’agit d’une machine basée sur des GPU et donc difficilement exploitable à sa pleine puissance sur une large gamme d’applications, les Chinois ont parfaitement réussi leur coup médiatique.

Le prix Gordon Bell récompense chaque année un accomplissement significatif dans le domaine du HPC (High Performance Computing), et plus particulièrement l’innovation dans la parallélisation d’applications scientifiques. Il a été décerné cette année au groupe de Georges Biros (Georgia Institute of Technology, Oak Ridge National Laboratory (ORNL) et New York University (NYU),) pour l’application Petascale Direct Numerical Simulation of Blood Flow on 200K Cores and Heterogeneous Architectures. Un groupe avec des représentants de l’EPFL (Simone Melchionna, Jonas Lätt) était parmi les finalistes, leur présentation a eu beaucoup de succès, malheureusement il n’y a qu’un vainqueur.

Dans une telle conférence où il y a presque dix sessions en paral-

férence SC10.....

lèle, il faut évidemment faire des choix, les sujets suivants ont plus particulièrement retenu mon attention.

À quand le premier superordinateur d’une puissance d’un exaFLOPS (1018) et ses caractéristiques ?

Les deux contraintes communément admises sont le prix (200 M$) et la consommation électrique (< 30 MW). Deux possibilités d’y arriver: à l’aide de GPU ou de processeurs plus classiques (10 fois moins de nœuds avec l’option des GPU). Dans les deux cas, il s’agira d’architectures hybrides et de progrès très importants qui devront encore être accomplis sur le plan de l’efficacité énergétique (il est nécessaire d’augmenter les performances d’un facteur 1000 en ne consommant que 10 fois plus d’électricité) et de la résilience des applications (la machine, vu le nombre de ses composants, devrait crasher 2-3 fois par jour…). Mais les spécialistes sont optimistes et avancent la date de 2018.

En 1988, un Cray Y-MP avec 8 processeurs a atteint la performance de 1 gigaFLOPS, en 1998, un Cray T3D avec 1024 processeurs a atteint 1 téraFLOPS, en 2008, un Cray XT5 avec 150’000 cœurs a atteint le pétaFLOPS, alors pourquoi pas l’exaFLOPS en 2018 avec une machine comprenant quelques dizaines de millions de cœurs.

Cela n’est pas si simple, et d’énormes progrès devront encore être faits sur le plan des modèles de programmation. Il sera nécessaire d’utiliser au mieux la localité des données, car le transfert de données à travers toute la machine consommera beaucoup trop d’énergie. Steve Scott, le CTO de Cray, affirme qu’effectuer une multiplication en virgule flottante sur 64 bits consomme 3 fois moins d’énergie que de déplacer les 3 opérandes de 64 bits de 20 mm dans la puce d’un CPU et il résume cela par «FLOPS are cheap, communication is expensive».

fig. 1 – maquette du BlueGene/Q (échelle 1:4)

Les économies d’énergie D’une façon générale, l’augmentation de la prise de conscience dans la communauté HPC de la nécessité d’augmenter l’efficacité énergétique des superordinateurs n’a jamais été aussi grande.

Comment prôner la simulation numérique pour étudier le climat si ces mêmes superordinateurs ont un impact significatif sur ce dernier ? z Un prototype de la prochaine génération de Blue Gene/Q (cf. figure 2 – photo d’un nœud de BG/Q, avec refroidissement liquide jusque sur les CPU et connexions à fibre optique) est en tête du Green 500 de novembre 2010 avec 1684 mégaFLOPS/W [1]. La liste montre que 15 parmi les 25 superordinateurs les plus efficaces sont des IBM. L’EPFL est au 20ème rang avec son BG/P (378 mégaFLOPS/W).

fig. 2 – node card du BlueGene/Q

z 1.4% de la consommation électrique aux USA est utilisée pour refroidir les ordinateurs. De nouveaux systèmes de refroidissement originaux et économiques apparaissent comme le refroidissement par bain d’huile [2]. Il s’agit d’une huile minérale qui n’est absolument pas toxique. Les ventilateurs sont ainsi inutiles, ce qui peut représenter une économie d’énergie d’environ 10 à 20%. Cette solution permet également d’augmenter la densité énergétique des racks (> 100 kW par rack).

Les disques durs sont rendus étanches grâce à une couche de paraffine. Des négociations sont en cours avec des constructeurs afin de ne pas perdre la garantie (cf. figure 3).

N° 10 SPÉCIAL CALCUL À HAUTE PERFORMANCE – 21 DÉCEMBRE 2010

43

Échos de la conférence SC10

fig. 3 – refroidissement par bain d'huile: les serveurs sont plongés dans de l'huile minérale

z Le design des datacenters a énormément évolué ces dernières années sous l’impulsion de Google, Microsoft, Yahoo ou Amazon. L’avènement du cloud computing a nécessité de construire de gigantesques datacenters, on parle actuellement de datacenter de 4ème génération. Alors que l’efficacité énergétique, appelée Power Usage Effectiveness (PUE, cf. figure suivante), de beaucoup de datacenters actuels se situent entre 1.5 et 3 (1 signifierait que toute l’électricité est utilisée par le matériel informatique), des PUE de l’ordre de 1.15 ne sont plus une utopie (seulement 15% d’énergie utilisée pour le refroidissement et les UPS). De nombreux centres de supercomputing ou d’universités américaines sont en train de construire de nouveaux datacenters plus efficaces en utilisant de nouvelles technologies (free cooling à air ou à eau, containers,…). Les datacenters sont désormais localisés là où l’électricité est la moins chère, comme en Oregon par exemple.

Certains affirment que les datacenters seront les usines du 21ème siècle.

POWER USAGE EFFECTIVENESS TOTAL FACILITY POWER UTILITY COMPANY

POWER IN

Power • Switchergear • UPS • Battery backup Cooling • Chillers • CRACs

- InfiniBand) pourrait apparaître d’ici 2-3 ans (les chipsets utilisés sont déjà très semblables).

Le domaine du stockage est en évolution, mélange de disques SSD avec des disques mécaniques pour augmenter les performances, mais il n’y a pas de révolution. Pour les grandes capacités, il n’y a toujours pas mieux que les bons vieux disques durs mécaniques.

Et ces besoins en capacité de stockage vont exploser. Un exemple donné lors de SC10 est celui du séquençage de l’ADN du génome humain. Le projet a été achevé en l’an 2003 et a coûté 3 milliards de dollars. En 2010, un génome humain peut être lu en 13 heures pour un coût de 10’000 $ (l’évolution est beaucoup plus impressionnante que celle de la loi de Moore) et cela génère plus d’un téraBytes de données brutes [3]. L’exploitation de dizaines, voire de centaines de séquenceurs de type Illumina HiSeq 2000 [4] va générer des quantités astronomiques de données.

La mode du cloud computing touche également le HPC Microsoft a annoncé l’intégration de Windows HPC Server à Azure (le cloud de Microsoft) afin de permettre à un client d’un centre de calcul de communiquer avec le système Windows Azure et de choisir la manière dont il souhaite répartir la charge de travail entre les systèmes locaux et ceux de Azure. Cela est surtout utile lorsqu’il y a des charges de travail qui présentent des pics importants, mais de façon temporaire.

Après la virtualisation des serveurs, la virtualisation des clusters sera disponible en 2011. IBM et Plateform Computing vont sortir de telles solutions (hypervisor Cluster).

La conférence SuperComputing 2011 [5] aura lieu en novembre 2011 à Seattle, la patrie de Microsoft et Bœing.

Références [1] www.green500.org/lists/2010/11/top/list.php; [2] www.grcooling.com; [3] www.economist.com/node/16349358/print; [4] www.illumina.com; [5] sc11.supercomputing.org/index.php n

IT EQUIPMENT POWER POWER IN

• Servers • Storage • Telco equipment

PUE = Total facility power + IP equipment power

Connectique Jusqu’à présent, à part les solutions propriétaires, le réseau d’interconnect dans le domaine du HPC était principalement du gigabit Ethernet (43%) et de l’InfiniBand (40%). Maintenant avec l’arrivée du 10GbE qui coûte 4 fois plus cher que le GbE mais offre 10 fois plus de bande passante, la question se pose de la concurrence entre l’InfiniBand et le 10 GbE. Le problème de la latence est critique, mais des solutions 10 GbE à faible latence apparaissent sur le marché (ex: Arista) et une fusion des 2 approches (10 GbE ISSN 1420-7192