http://dit.epfl.ch

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

21.12.201010

tout public public averti expert

SPÉCIALCALCUL

ÀHAUTE

PERFOR-MANCE

ActualitésCADMOS 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

AnalyseLa 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 micro- evaporators J. Marcinichen, J. Olivier & J. Thome 29

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

À votre serviceL’expérience SuperB V. Rezzonico 21

Grille de calcul nationale P. Jermini 24

Calculons au DIT ! M. Thiemard 27

Le calcul scientifique est un outil fon-damental pour la recherche. Pour la troi-siè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 supercalcula-teur avec une efficacité énergétique jamais vue, d'évacuer la chaleur proche des com-posants 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 pro-blè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é à

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

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 Informa-

tique 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

Actualités

ConcoursProposez 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.

Prochaines parutions

No Délai de rédaction Parution

1 06.01.11 25.01.11

2 03.02.11 22.02.11

3 10.03.11 29.03.11

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

ImpressumLes 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

Rédacteur en chef:Vittoria Rezzonico fi@epfl.chMise en page & graphisme:Appoline Raposo de BarbosaComité 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 Viceic & Jacques VirchauxImpression: Atelier de Reprographie EPFLTirage: 4000 exemplairesAdresse Web: dit.epfl.ch/FI-spipAdresse: Domaine IT EPFLCP 121, CH-1015 Lausanne 15Téléphone: +4121 69 32246 & 32247

Lorsque les étoiles s’estompent, CADMOS brille plus fortVincent.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 computa-tional 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 Chal-lenges of EPFL described in 1993 in a paper written by Marie-Christine Sawley.

CADMOS [1] vous connaissez ? Acronyme pour Cen-ter for Advanced Modeling Science, le projet CAD-MOS a été lancé fin 2009 comme collaboration entre l'EPFL et les universités de Lausanne et de Ge-nè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:

1 la compréhension des régimes turbulents en 3D sur des géo-métries complexes dans la dynamique des fluides computa-tionnelle (CFD),

2 la physique des plasmas,3 la physique de la matière condensée et la dynamique molécu-

laire,4 le traitement des signaux.Ces quatre Grand Challenges permettaient de démontrer le be-soin 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 tou-jours 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’ac-tualité. Elle consistait en cinq objectifs que je vous livre in extenso:1 développer ou adapter en collaboration avec CRAY des appli-

cations 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 pour-ront être résolues sans recourir à des machines avec des puis-sances 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.

Actualités

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

Quelles sont les applications Grand Challenges aujourd’hui ?

2010, sur l’arc lémanique

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 philo-sophique ou morale, un organisme vivant est d’une complexité colossale et ce n’est pas après-demain que l’être humain sera ca-pable de simuler un organisme entier, même simple, sur un sup-port 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 pro-jets 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 simu-lations 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 Car-Parrinello 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-

nal Theory) et la TDDFT (Time-Dependent DFT). Ces nouvelles tech-niques 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 (ha-dronthé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 applica-tions 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

La fusion thermonucléaire contrôlée pour la production d’éner-gie 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 Experi-mental Reactor) actuellement en construction à Cadarache dans le sud de la France [6]. À travers le CRPP, l’EPFL est depuis long-temps 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’Univer-sité 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’ap-proche 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 computa-tionnelle (CFD) est l’un des pères fondateurs du calcul à haute per-

Lorsque les étoiles s’estompent, CADMOS brille plus fort

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

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’acci-dent 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 phy-sique 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’ori-gine 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 vi-vant. 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.

Lorsque les étoiles s’estompent, CADMOS brille plus fort

Effets de bord et futur

Du côté de l’enseignement, un master en sciences computation-nelles 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, trou-ver 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 simu-lation 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, Cardio-vascular Mathematics, modeling and simulation of the circu-latory 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

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 puis-sance 12 opérations en virgule flottante à la seconde.

GLOSSAIRE &Modèle par échange de messages:

modèle de communication entre processus. Chaque processus com-munique 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.

MPI/PVM (Message Passing Interface/Parallel Virtual Machine): normes défi-nissant 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 plu-sieurs implémentations de MPI (comme

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

This paper describes Moore's Law, as it was phrased in 1965 by Gordon Moore (Intel cofounder) includ-ing 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-fonda-teur 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 mon-diale 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 respectueu-sement par les grands pontes du comité d’organisation. 4000 per-sonnes, 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, mi-nuscules 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 quit-tera bien vite pour fonder Fairchild avant d’être ensuite un des co-fondateurs 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-

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

vrait avoir aujourd’hui des puces de 2 millions de milliards de transistors, ce qui n’est évidemment pas le cas, puisqu’un micro-processeur 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 double-ment 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 !». Fina-lement, en observant le nombre de transistors des microproces-seurs 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édic-tions 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 tech-niques à 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-

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

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 for-maient 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 ca-nons 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 al-lant –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 tra-vailler 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

Analyse

croprocesseurs. Il y a beaucoup de travaux de recherche pour em-piler 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 technolo-giques à 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 pro-chaines 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 cir-cuits 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 for-ment 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

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

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

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

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 ex-pert 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 tra-vail de programmation et de debugging, puis la phase de vali-dation qui consiste à comparer la solution calculée sur ordi-nateur 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 parti-culier, 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

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 re-

liant 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étermi-nistes ou stochastiques. Par exemple, les principes de conser-vation 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 Pro-blems 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

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

L'écriture des fichiers des résultats de simulations numériques est depuis longtemps le goulot d'étran-glement du calcul à haute performance. La visuali-sation 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ésen-tations 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 cre-ate 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 us-ing 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 access-es. 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 visuali-zation: 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 pro-poses tutorials in in-situ visualization. In fact, not just one, but two libraries in open-source form were demonstrated. The Para-View package proposes a co-processing toolkit [1] while the VisIt

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 dif-ferential 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 maxi-mum number of iterations is reached. What happens in between can be a long story. The programmer is faced with many chal-lenges. 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 to-day’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 do-ing 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 simula-tions. 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-pro-cessing 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 visu-alization, 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 inter-active 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 visualizationJean M. Favre, jfavre@cscs.ch, CSCS (Swiss National Supercomputing Center), Visualization Software Engineer

Analyse

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

Serve a VisualizationRequest?

Solve Next Step

Check forconvergence or,

end-of-loop

Exit

Initialization

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 visualiza-tion scenario must be encoded. At any time while the simulation executes, VisIt’s GUI will be able to connect and disconnect from it.

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:

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!

Data Access

The main premise of in-situ visualization is to gain access to the memory contents of the simulation. Both C and FORTRAN simula-tions 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 vari-ables, at any timestep, and for any parallel compute nodes partici-pating 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 adver-tized, 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 codeallocate (T(XX, YY))nTuples = XX * YY

visitvardatasetd( h, VISIT_OWNER_SIM, 1, nTuples, T)

// C codefloat *T = malloc(XX * YY * 4);nTuples = XX * YY;VisIt_VariableData_setDataF( h, VISIT_OWNER_SIM, 1, nTuples, T);

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 dlo-pen() call when the connection is first established, is then free to use the pointer in read-only mode, to construct the visualiza-tion 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 alloca-tions 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_OWN-ER_COPY would distinguish this case.

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

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

Interaction with the simulation

Interaction with the simulation can be done through a command panel with buttons enabling iteration controls such as next, up-date, 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-

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 pic-tures. 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 rigor-ously 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 con-ditionally compile the VisIt in-situ support, and then launch their simulation and connect the GUI with it.

References

[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/DataManualExam-

ples/Simulations/contrib/pjacobi/ n

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

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

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

Akantu signifie petit élément en kinyarwanda, une langue bantoue. Désormais, c’est également une bi-bliothè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 open-source object-oriented library which has the ambi-tion to be generic and efficient.

Within LSMS (Computational Solid Mechanics Laboratory, lsms.epfl.ch), research is conducted at the interface of mechanics, ma-terial 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 compu-tationally 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 math-ematical 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 addi-tion, 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 par-allel computation.In order to achieve these goals, we made noticeable choices in

An optimized finite-element library: AkantuNicolas.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

the architecture of Akantu. First we decided to use the object-oriented paradigm through C++. This paradigm is useful in terms of genericity and code factorization. In fact, it relies on the con-cepts 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 com-mon interface to material objects contains a function that com-pute 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 func-tion 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 imple-mentations. 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 manipu-lations, 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 natu-rally 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 ap-proach, 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 vir-tual 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, oper-ate on the entire set of elements. The counter part is that generic-ity is reduced when compared to a full object view: the high level classes contain now more complex functions.

materialvirtual computeStress (in strain)

elasticcomputeStress (in strain)

plasticcomputeStress (in strain)

fig. 1 – inheritance schematic of material classes

Analyse

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

models steel during a normal compression. Comparative results are presented on figure 4.

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 ge-neric 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 approxi-mately 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 su-per scalar effect is observable with 4 processors. This must be due to communications overlap and important processor cache ef-fects. 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.

1

2

4

8

16

32

64

1 2 4 8 16 32 64

Sp

eed

up

Number of processors

SpeedupIdeal speedup

We presented the main choices taken in the development of Akan-tu 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 encourag-ing. They tend to prove that these choices show nice performance speedup while our needs for genericity were maintained at a rea-sonable 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

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 se-lect 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 solu-tion 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 have been sorted by element types so as to break loops over elements as said above. Con-cerning a complete finite-ele-ment sequence, that contains gradient computation, con-stitutive law call, integration and assembly, the vectoriali-zation imposes a specific task organisation. Global tasks can be divided in simple opera-tions and pipelined in order to obtain the desired result, as shown in figure 3. The crucial point here is that these SIMD (Simple Instruc-tion Multiple Data) operations are in fact well optimized by nowadays compilers. These 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 Finite-Element 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

strain

stress

Gradient

Constitutive law

displacement

Integration

Assembly

integral form

residualfig. 3 – pipeline of vectorial opera-tions used to compute nodal resi-duals from nodal displacements

a) Full object architecture

Mesh

nodes

connectivity

b) Object/vectors architecture

Mesh

elements

connectivitynodes

virtual interpolate ()virtual integrate()

Element

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

An optimized finite-element library: Akantu

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

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

Simulations de systèmes astrophysiques au LASTROYves.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, repo-sant sur une physique complexe et variée.Les ressources HPC sont des outils indispensables pour l'explorer.

Les simulations numériques astrophysiques sont devenues incon-tournables pour étudier des systèmes physiques dont la taille et le temps dynamique dépassent complètement l’homme. Elles per-mettent 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 étu-dié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 gravitation-nelles 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 ins-tant 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 per-met 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 parti-cule 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’al-gorithme 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’approxima-tion 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’hydro-dynamique, 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 hydro-dynamiques 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

Analyse

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

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érar-chique de l’espace, nécessaire pour le calcul des forces gravita-tionnelles, 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 conden-ser, 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 ac-tuels. 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 su-pernova. 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 du-rant 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 capa-cité à se refroidir.

Code et stratégie de parallélisation

Le squelette du code utilisé au LASTRO est basé sur le code Gad-get-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.

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 unique-ment ces mêmes particules locales comme source du champ gravitationnel.

2 Si une particule nécessite de recevoir des forces supplémen-taires, 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 com-plètent les forces en utilisant leurs particules locales comme source et les retournent ensuite au processeur qui les a en-voyé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 à dif-férents types de systèmes astrophysiques. Nous décrivons ci-des-sous 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 spiralesDepuis 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 étu-diant 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

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

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 com-posant baryonique, faiblement dissipatif. L’auto-gravité de cette matière la rend très légèrement instable et engendre des bras spi-raux détectés par l’observation de l’hydrogène neutre.

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 mo-dèle. Les spirales formées par la matière noire sont tracées par l’hydrogène neutre observé.

L’évolution chimique des galaxies nainesPrendre 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. 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.

La formation des structures cosmologiquesLe 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. 4 – l’Univers après 1 milliard d’années, dans un cube de 300 millions d’années-lumiè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.

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 observa-tions 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

Simulations de systèmes galactiques et extra-galactiques au LASTRO

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

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’obser-vation (Baek 2009, Baek 2010).

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., Reio-nization by UV or X-ray sources, 2010, Astronomy and Astro-physics, 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, As-tronomy and Astrophysics, Volume 524. n

Rencontre entre deux géants. Dans environ 4.5 milliards d’années, la grande ga-laxie 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.

Simulations de systèmes galactiques …

Computational science is a multidisciplinary field connecting computer science with physics, chemis-try, 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 Com-putations), recently installed on campus, and the collaborative Lemanic project CADMOS (Center for advanced Modeling Science), whose BlueGene/P su-percomputer 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 com-putational sciences has been boosted last year with the creation of the Master in Computational Sci-ence 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, biolo-gie, 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écu-laire) récemment installé sur le campus ou au sein du projet collaboratif lémanique CADMOS (Center for Advanced Modeling Science, dont le supercal-culateur BlueGene/P en est la partie la plus visible) ou dans l’industrie, avec plusieurs start-ups ou spin-offs 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

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 sup-planter, 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

Master CSE: un atout pour l’ingénieur du futur !Vincent.Keller@epfl.ch, EPFL – CADMOS & Simone.Deparis@epfl.ch, EPFL – MATHICSE

Actualités

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

Master CSE: un atout pour l’ingénieur du futur !Vincent.Keller@epfl.ch, EPFL – CADMOS & Simone.Deparis@epfl.ch, EPFL – MATHICSE

composants a été simulée avant d’être réellement construite et testée ? Qui ne connait pas ITER, le prototype de fusion thermo-nucléaire contrôlée pour la production d’énergie primaire dont les aspects de chauffage – notamment – sont analysés par la simu-lation 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 en-treprise. 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 per-mettent 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 Tech-niques 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 di-rectrice 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’in-dustrie, 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éma-nique 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 Docto-rat 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 for-mation 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 perfor-mance 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.

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

Qu’est-ce qu’InfiniBand ?David Cervini, cervini0@etu.unige.ch, étudiant à l'Université de Genève

Analyse

With 42.6% of the Top500 supercomputers featur-ing 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’intercon-nexion entre nœuds de calcul et leurs périphériques d’entrée-sor-tie. 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 Vol-taire. 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 res-sources 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 rela-tifs à 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-

lui lié au réseau (zero copy feature). Cela se fait par le InfiniBand messaging service: une application y accède directement court-circuitant ainsi l’OS (stack bypass).InfiniBand relie une application et son espace d’adressage directe-ment à 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'adres-sage 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 appli-cation a accès directement à la mémoire virtuelle de l’autre appli-cation (de manière contrôlée).

Opérations exécutées par les QPIl 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 directe-ment à 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 applica-tions d’accéder au réseau: les QP fournissent aux applications le moyen de contrôler le HCA.

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

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 vir-tuelle/physique et valide les droits d’accès.

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

Les spécificités de la couche liaison

Virtual Lanes & qualité de serviceIl 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.

Contrôle de flux point à pointIl 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épen-dant 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 buf-fers propres, ce système s’applique à chaque paire.

RoutageLe routage par les switches est statique: la destination des pa-quets 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 Ma-nagement 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 rou-tage, comme on le voit sur l’exemple.

Qu’est-ce qu’InfiniBand ?

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.

1

1

1

1 2 3 4

1 2 3 4 5 1 2 3 4 5

A1/A2 B1 /B2 C1/C2 D1 /D2 E1 /E2

LFT 2.2____________DLID PortA1 1A2 2B1 1B2 2C1 3C2 3D1 4D2 4E1 5E2 5

LFT 1____________DLID PortA1 1A2 2B1 1B2 2C1 3C2 4D1 3D2 4E1 3E2 4

LFT 2.1____________DLI PortA 3A 3B 4B 4C1 1C2 2D1 1D2 2E1 1E2 2

1 1

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

Conclusion

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 environ-ments, 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!

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

500

400

300

200

100

0

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

100

80

60

40

20

0

Mac

hine

s%

Flo

ps

Gigabit ethernet Infiniband Myrinet other interconnect

é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écri-vant plus en détail tous les aspects de l’architecture d’InfiniBand.

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

Bibliographie

[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 effec-tuer sur les QP: création, soumission d'une requête, récupéra-tion du résultat et configuration du Channel Adapter.

Qu’est-ce qu’InfiniBand ?

HPC Advisory Council Switzerland Workshop 2011Lugano – 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ésenta-tions sur des thèmes autour du HPC.Pour plus d'informations, vous pouvez visiter le site Web de hpc-ch: www.hpc-ch.org.

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

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

À votre service

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 adminis-tration 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 cou-rants 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 sur-booké 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épen-dance 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 appar-tiennent à un petit groupe de personnes, ils sont parfois sous-uti-lisé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

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

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

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 per-dus 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’im-

porte 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 impo-sé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 admi-nistratifs 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 der-niè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 ordonnan-

ceur 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).

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

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 labora-

toire 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 dif-fé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 directoriesLes 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 jobsLes 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 tou-

jours 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-Mas-ter, 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 ser-veur 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.

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 NISLes 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 directoriesLes répertoires homes seront accessibles au chemin /home/user-name depuis tous les nœuds et les frontends, et seront stockés dans /srv/home/username sur leur master, ou sur SuperB si l’uti-lisateur 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 schedulerAvant 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 accommo-der cette quantité non standard de données de configuration des files d’attente.

file d'attente qui a accès nombre de noeuds aux-quels la queue a accès

batch tout le monde l0+l1+l2+i0institut0 membres de l'institut i0inst0lab0 membres du lab0 l0 + i0inst0lab1 membres du lab1 l1 + i0lab2 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’inter-rompre brusquement le job par un signal KILL, et ensuite le re-mettre 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.

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

Par défaut, la queue de routage enverra le job dans la file la plusrestrictive (celle du labo). Si on est propriétaire et que l'on sou-haite 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 direc-tion 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écon-seillé pour plusieurs raisons (plus de complexité dans le preemp-ting, 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èleSeul 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. Sprin-ger-Verlag.n

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

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

A computing grid is set up in Switzerland to provide computational resources to solve scientific compu-tationally 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 par-ticipants.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 adminis-tratif (ou d’une institution), plusieurs problèmes commencent à émerger, notamment l’authentification et l’autorisation des uti-lisateurs 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 institu-tions 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 ges-tionnaires de ressources locaux (LRMS: Local Ressources Manager

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éophy-sique (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éploie-ment d’autres applications reste possible, une fois que leur apti-tude a s’exécuter dans l’environnement SMSCG a été évaluée. Si nécessaire, le projet offre aussi une équipe de support pour assis-ter 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 com-posante 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 (HES-SO), 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'as-pect 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] www.smscg.ch[3] www.swing-grid.ch[4] www.switch.ch/aaa/[5] www.nordugrid.org/arc/ n

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

À votre service

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

À 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 pre-sented 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 dispo-nibles 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.

2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

?

?

?

?

?

?

Blue Gene/P

GPUs NVIDIA

Cell/B.E

Jupiter

Vega

Antares

Callisto

Greedy

?

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 consor-tium CADMOS (Center for Advanced Modeling Science) et est hébergé et administré par le DIT. Il est accessible aux membres

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.chWeb: bluegene.epfl.ch.

Callisto, Antares & Vega

Trois clusters généralistes sont accessibles.Callisto, datant de juin 2008, est constitué de 128 nœuds bi-processeur 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 Cal-listo.

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.chWeb: hpc-dit.epfl.ch/generalpurpose.php.

Jupiter

Jupiter n’est pas seulement la plus grande planète de notre sys-tè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.chWeb: 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-pro-cesseur 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

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

Since 1993, the small world of high performance computing focuses nearly exclusively on the pub-lication of the top500 [1] lists during the Interna-tional Supercomputing Conference in June and Su-perComputing in November to rank the worldwide supercomputers. Since June 2008, the top500 list proposes an estimation of the energy consump-tion 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 consom-mation électrique des superordinateurs. Parallèle-ment, 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 simi-laire mesuré à l'EPFL[4]) sont celles qui sont dominées par des ac-cè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é,

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.chWeb: 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 pro-priétaire des nœuds de calcul est toujours prioritaire sur toute acti-vité 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’infras-tructure. Ce sont des machines virtuelles à 2.5Ghz avec chacune 3GB de mémoire installées sur les anciens serveurs de l’infrastruc-ture 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.chWeb: 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ète-ment 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 utilisa-teurs. 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 plai-sir de vous aider et de vous conseiller dans le choix de la ressource la plus adaptée. n

Calculons au DIT !

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 24z MPI, an introduction to parallel programming (in En-

glish) N° 11-0016 – from April 5 to 8z 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.

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

permet de tirer la performance maximum d'un nœud de calcul. On a même entendu dire que les constructeurs de chips ajou-taient quelques portes logiques et transistors ciblés à leur hard-ware 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 plu-tôt qu'un benchmark conçu à l'origine pour les architectures vec-torielles. 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 exac-tement 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 consomma-tion énergétique totale de celui-ci. En informatique en général, en sciences computationnelles en particulier, l’efficacité éner-gé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 fonc-tion 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 im-médiatement: est-il possible de construire une machine avec la technologie existante qui serait capable de produire 1 GF sur une

Entre efficacités computationnelle et énergétique

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

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 hy-pothè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 cores4 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

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

é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. Fina-lement, 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.

Phase 11 x GTX280

1.3 GHz4 GB memory

240 cores

Phase 24 x GTX2800.375 GHz

1 GB memory per card4 x 240 cores

Phase 34 x GTX2800.375 GHz

1 GB memory per card4 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

M∞ [Gw/s] 17,7 4,43 4,43

Mnode [GB] 4 1 1

RSMXV [GF] 10 2,5 2,5

W [W] 236 11 6,5

W/RSMXV [J/GF]* 24 4,4 2,6

+50% AC** 36 6,6 3,9

Coût [CHF] 1800 1600 1400

* énergie par GF sur le benchmark SMXV** additionné de 50% de la valeur W/R SMXV pour le refroidissement (AC=Air Condi-

tioning 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 per-formance é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

HPC@GreenIT: entre efficacités computationnelle et énergétique

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 (sus-tained 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

Qui dit quatre fois plus de matériel, dit qu’une densification des composants est obligatoire. D’autant plus qu’une bonne par-tie 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 suc-cè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’appli-cations non dominées par la bande passante mémoire, la perfor-mance 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 techno-logie 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 pro-metteurs 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’atmos-phè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

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

La consommation d’énergie devenant un problème important pour les fabricants de matériels informa-tiques et les opérateurs de serveurs, de nouvelles solutions sont nécessaires pour réduire cette de-mande. L’amélioration des techniques de refroidis-sement des microprocesseurs est un des domaines où les plus grandes avancées sont possibles. L’ex-périence du LTCM dans le refroidissement par sys-tè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 alu-minium peuvent refroidir de très hauts flux de cha-leurs (jusqu’à 350 W/cm2), assurer la stabilité et l’uniformité des températures et permettre la ges-tion 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.

With energy consumption becoming a huge concern amongst hardware manufacturers and data center operators, novel solutions to reduce this consump-tion needs to come to light. Cooling of microproces-sors 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 boil-ing 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, micropro-cessor 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 cool-ing). 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 air-cooling, 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 capac-ity 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 cent-ers 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.

0.01

0.1

1

10

1.0E-07 1.0E-06 1.0E-05 1.0E-04 1.0E-03 1.0E-02 1.0E-01 1.0E+00Qp/Qt

Rh

s,Kcm

2 /W

Microchannel- Single-phase

Porous Media - SP

Porous Media - TP

Jet Impingement

Microchannel- Two-phase

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 publica-tions show the development of primarily four competing tech-nologies 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

Analyse

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

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

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

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 reac-tive ion etching (DRIE) within a joint project with IBM.

It is worth noting that what happens in small channels in two-phase 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 fric-tion 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 diam-eters of 5-10 μm. This is not the case for macroscale two-phase flow methods, which usually do not work very well when com-pared 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 micro-scale. 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 mac-roscale 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

quite uniform. Interpreting these images and many others avail-able 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 up-per 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. 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 de-termine 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 bub-bles), coalescing bubbles and annular flow (thin liquid film with vapor core).

On-chip cooling using micro-evaporators

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

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

Jacobi and Thome [8] proposed the first theoretically-based, elon-gated bubble (slug) flow boiling model for microchannels, model-ling 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 mecha-nism controlling heat transfer in slug flows in microchannels, not nucleate boiling as assumed by others in extrapolation of macro-scale 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 includ-ing 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 time-averaged heat transfer rate at a fixed location along a microchan-nel 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) and3 a vapor slug passes if the thin evaporating film of the bubble

dries out before the arrival of the next liquid slug. The cycle

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 tri-plet pass this fixed point at a frequency f that is a function of the formation and coalescence rate of the bubbles upstream.

Lp

Lv Ll

δδmin

q

Ldry Lfilm

dryzone

elongatedbubble

liquidslug d

R

(a)

...

Instant t0

Instant t0+τ

1 2 3 4 5 6

1 2 3 4 5 6

(b)

0

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 adja-cent 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 lo-cation 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, momen-tum 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 wave-length criterion (assuming the height of the waves scales propor-tional to the critical wavelength), the wave height was modelled with the following empirical expression:

=0.15uG

uL

37 g L G( ) di 2( ) 2

17

.

Then, when δ equals Dδ 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-

On-chip cooling using micro-evaporators

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

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 satisfac-torily 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 rectangu-lar 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]. Further-more, this model also predicts CHF data of CO2 in microchannels from three additional independent studies as well as other fluids.

0 2 4 6 8 10 12 14 16 18 200

50

100

150

200

250

Heated length [mm]

Rad

ius

[µm

]

Wave heightFilm thickness

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 sec-tions can suffer from flow maldistribution, two-phase flow insta-bilities 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

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 stag-nant, (e) and (f), before moving forwards or backwards again.

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 maldistribu-tion 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 evap-orators 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

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

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 resist-ances) 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 consider-ably 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 char-acterize 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.

0

10

20

30

40

50

60

70

0 20 40 60 80 100

Dat

a C

ente

r P

ower

Sup

ply,

M

W

Energy Recovery Efficiency, %

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

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

References

[1] Koomy, J.G., Estimating Regional Power Consumption by Servers: A Technical Note. 2007, Lawrence Berkeley National Laboratory: Oakland, CA.

[2] Saini, M. and Webb, R.L., Heat Rejection Limits of Air Coo-led Plane Fin Heat Sinks for Computer Cooling. IEEE Tran-sactions on Components and Packaging Technologies, 2003. 26(1): p. 71-79.

[3] Samadiani, E., Joshi, S. and Mistree, F., The Thermal Design of a Next Generation Data Center: A Concep-tual Exposition. Journal of Electronic Packing, 2008. 130: p. 041104-1 - 041104-8.

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

[5] Leonard, P.L. and Phillips, A.L. The Thermal Bus Opportu-nity – A Quantum Leap in Data Center Cooling Potential in ASHRAE Transactions. 2005. Denver, CO.

[6] Wolverine Tube Inc, www.wlv.com/markets/electronic-coo-ling.html. 2010.

[7] 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.

[8] Jacobi, A.M. and Thome, J.R., Heat transfer model for eva-poration of elongated bubble flows in microchannels. Jour-nal of Heat Transfer-Transactions of the Asme, 2002. 124(6): p. 1131-1136.

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

[10] 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.

[11] Wojtan, L., Revellin, R. and Thome, J.R., Investigation of saturated critical heat flux in a single uniformly heated mi-crochannel. Experimental Thermal and Fluid Science, 2006. 30: p. 765-774.

[12] 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.

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

[14] 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.

[15] 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. Interna-tional Journal of Heat and Mass Transfer, 2008. 51(21-22): p. 5426-5442.

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

[17] 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 Technolo-gies, Accepted for publication, 2010. n

On-chip cooling using micro-evaporators

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

Une nouvelle conception des systèmes multiproces-seurs 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 sys-tems.

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, supply-ing 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 de-sign 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 thermal-aware 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 Labora-tory 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 de-ployment of the energy-efficient run-time thermal control strate-gies to achieve energy-efficient cooling mechanisms to compress almost 1 Tera nano-sized functional units into one cubic cen-timeter 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 me-chanical-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 two-phase to novel engineered environmentally friendly nano-fluids, as well as using specifically designed micro-channel arrange-

ments, in combination with the use of dynamic thermal manage-ment 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 in-crease 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 ar-rival of chip multi-core and multi-threaded processors, supply-ing 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 deploy-ment 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.

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

U.S. Market

$90

$80

$70

$60

$50

$40

$30

$20

$10

$ 0

18

16

14

12

10

8

6

4

2

01996 1998 2000 2002 2004 2006 2008

Spending (US$B)

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, mem-ories, 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 design-ing 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-Processors David.Atienza@epfl.ch, professor EPFL - Embedded Systems Laboratory

Analyse

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

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 exacer-bate 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 3D-based HPC systems.

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

fig. 2(b) – transient thermal map (in K) of the Sun-based 50-core MPSoC emula-ted 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

address the high temperatures in 3D MPSoCs, due to the higher heat removal capability of liquids in comparison to air. This tech-nology being developed by the CMOSAIC Nano-Tera.ch RTD pro-ject, as shown in Figure 3(a)(b), involves injecting water through micro-channels between the tiers of a 3D stack. This cooling tech-nology 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 3 (b) – 3D stacked MPSoC with inter-tier liquid cooling

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 cool-ing-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

Thermal-Aware Design for 3D Multi-Processor

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

temperature distribution in the target 3D MPSoC designs. Figure 4 shows layouts of these 3D MPSoCs targeted with this liquid cool-ing 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. 4 – Sun-SPARC 3D MPSoCs layouts with inter-tier liquid cooling

Then, Figure 5 shows a detailed inter-tier cooling internal struc-ture 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 finite-element methods (FEM). FEM-based thermal and cooling explora-tion 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 require-ments. Hence, at ESL we have developed 3D-ICE [1] (or 3D In-terlayer 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 of-fers 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.

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 dis-charge rates at small pressure heads. Then, liquid is injected to the stacks from this pump via a pumping network. To enable differ-ent 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.

Thermal-Aware Design for 3D Multi-Processor

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

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

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

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

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 data-center 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 en-ergy 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

10

8

6

4

2

0

Valve Pump

Co

olin

g p

ow

er c

on

sum

pti

on

per

stac

k (W

atts

)

Flow rate per stack (L/min)

0.01 0.02 0.0323

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 con-trollers 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 tempera-ture based on Auto-Regressive Moving Average (ARMA) models and proactively set the liquid flow rate using the pump controller.

Monitor Temperature

3D MPSoC

Forecast Maximum Temperature (ARMA)

CONTROLLER:Flow Rate Adjustment

SCHEDULER:Temperature-Aware

(Weighted) Load Balancing

Change in Maximum Temperature?

NO YES

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 cool-ing 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 state-of-the-art temperature controllers for MPSoC architectures using air cooling, i.e., dynamic load balancing (AC_LB), temperature-triggered task migration (AC_TTMig) or temperature-triggered dynamic frequency and voltage scaling (AC_TDVFS).

100

80

60

40

20

0

AC_LB AC_TTMig AC_TDVFS AC_TTMig_TDVFS LC_LB LC_Fuzzy

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

% h

ot

spo

ts (

>85

C)

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 tech-nology solution to overcome the thermal challenges of 3D MP-SoCs 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 de-velopment of novel system-level thermal-aware design meth-odologies, 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 par-tially 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 do-nation of the OpenSPARC University Program of Sun Microsys-tems-ORACLE for ESL.

References

[1] 3D-ICE: Fast compact transient thermal modeling for 3D-ICs with inter-tier liquid cooling, Arvind Sridhar, Alessan-dro Vincenzi, Martino Ruggiero, David Atienza, Thomas Brunschwiler, Proc. of International Conference on Compu-ter-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/3d-ice.html.

[2] Fuzzy Control for Enforcing Energy Efficiency in High-Perfor-mance 3D Systems, Mohamed Sabry, Ayse K. Coskun, David Atienza, Proc. of International Conference on Computer-Ai-ded 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 Stac-ked 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: 978-3-9810801-6-2, pp. 1 - 6, 8-12 March 2010. n

Thermal-Aware Design for 3D Multi-Processor

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

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ères-le-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 pro-blématique des infrastructures des centres de calcul hébergeant des ressources HPC supérieures à plusieurs MW.

La maîtrise de l’énergie

Pour faire fonctionner ces Formule 1 du FLOPS & il faut évidem-ment 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.

10.111.0

12.012.9

13.814.7

15.616.6

17.518.418.2

17.216.215.214.213.212.211.210.2

9.21 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2

Millions de CHF/an

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.

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

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%.

50 40 30 20 10

2 1.67 1.43 1.25 1.11

impact du PUE

puissance liée au calcul , à l’infrastructure

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

Évolution des coûts

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 fonc-tionnement dont la facture énergétique.La mise en place de génératrices de cogénération ou de trigénéra-tion 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 opti-misé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).

Actualités

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

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 infrastruc-tures utilisent l’eau comme composant essentiel de refroidisse-ment, 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’éco-nomies 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 se-lon 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 sud-ouest 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

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

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’ar-ticle 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 consom-mation é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 long-temps, 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-sys-tems;

[3] www.ivec.org/pawsey/index.html;[4] www.green500.org [5] www-03.ibm.com/press/us/en/pressrelease/27816.wss. n

HPC: l’énergivore

GLOSSAIRE &CEA: Commissariat à l’Energie Atomique

CSCS: Swiss National Supercomputing center

FLOPS (FLoating point Operations Per Second): nombre d’opéra-tions à virgule flottante par seconde.

LRZ: Leibniz-Rechen Zentrum.

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 consom-mée par les matériels informatiques.

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

UPS (Uninterruptible Power Supply): alimentation secourue.

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

The NVIDIA GPU Technology conference is a meet-ing point for developers, engineers and researchers using the computing power of graphic cards (GPUs) to be up to the newest challenges in scientific com-puting. Jen-Hsun Huang, CEO and co-founder of NVIDIA, Klaus Schulten, one of the pioneers of bio-informatics at Illinois University at Urbana-Cham-paign 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 es-pace de rencontre pour les développeurs, ingénieurs et chercheurs qui utilisent la puissance des proces-seurs graphiques (GPU) pour résoudre les défis de calcul les plus critiques. Jen-Hsun Huang CEO et co-fondateur de NVIDIA, Klaus Schulten de l'Univer-sité de l'Illinois à Urbana-Champaign, un pionnier dans le domaine de la bio-informatique et Sebas-tian 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 Im-

plementation (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 (Na-tional 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 tech-niques. 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

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

L’ensemble est tiré d’un article de David A. Patterson (2007): Com-puter 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 Archi-tecture. 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 pro-gramme 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 Am-ber-Charmm) benchmark a montré qu’avec 192 processeurs quadri-cœurs du superordinateur Kraken (Oak Ridge National

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

Actualités

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

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 architec-ture sur une technologie 22nm qui offrirait des perfor-mances 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 System-on-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/sor-ties 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 uti-lisent 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 net-books se connecteront directement au cloud.

Adobe Plenoptic Lens: présentation d’un produit qui pourrait bien révolutionner la photographie à en croire Adobe: trans-former 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 clus-ter 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.

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 errors occurring only at pins.

As chips drop below 65 nm feature sizes, they will have high soft and hard error rates.

4 By building upon prior successes, continue raising level of abstraction and size of HW designs.

Wire delay, noise, cross coupling, reliability, clock jitter, design valida-tion, … stretch development time and cost of large designs at ≤ 65 nm.

5 Researchers demonstrate new architectures by building chips.

Cost of 65 nm masks, cost of ECAD &, and design time for GHz clocks ⇒ 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-ture innovation. Branch prediction, OOO execution, spe-culation, VLIW, …

is the ILP wall: Diminishing returns on finding more ILP.

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-mance improvement.

Processors Parallelism is primary method of performance improvement.

11 Don’t bother parallelizing app, just wait and run on much faster sequential computer.

No one building 1 processor per chip.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.

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

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

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 elle-même de plusieurs dizaines de mini-lentilles avant le capteur CCD. W

W = tiré de Wikipédia

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 GPU-Based 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’assem-blage 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 nou-vel ordinateur chinois basé aussi sur des GPU a atteint les 2.566 pétaFLOPS ce qui lui a permis de se positionner en pre-miè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’Elli-son lors de la présentation annuelle d’Oracle à San Francisco: «Vous allez nous voir acheter des constructeurs de proces-seurs». 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

GPU Technology Conference 2010

Exascale computing and energy efficiency were among the most important subjects debated dur-ing 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 consomma-tion 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 tech-niques 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 Bour-bon 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 puis-sant au monde (www.top500.org/) quelques jours avant l’ouver-ture 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 accomplis-sement significatif dans le domaine du HPC (High Performance Computing), et plus particulièrement l’innovation dans la paral-lé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 Architec-tures. Un groupe avec des représentants de l’EPFL (Simone Mel-chionna, 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-

Actualités

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

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

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 refroidis-sement 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’aug-menter 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 construc-teurs afin de ne pas perdre la garantie (cf. figure 3).

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

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 com-posants, 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éces-saire 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».

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 su-perordinateurs les plus efficaces sont des IBM. L’EPFL est au 20ème rang avec son BG/P (378 mégaFLOPS/W).

ISSN 1420-7192

É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 der-niè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 actuelle-ment 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 si-tuent 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 utili-sé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 uti-lisant 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

UTILITYCOMPANY

TOTAL FACILITYPOWER

Power• Switchergear• UPS• Battery backup

Cooling• Chillers• CRACs

IT EQUIPMENTPOWER

• Servers• Storage• Telco equipment

POWER IN POWER IN

PUE = Total facility power + IP equipment power

Connectique

Jusqu’à présent, à part les solutions propriétaires, le réseau d’in-terconnect dans le domaine du HPC était principalement du gi-gabit 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 concur-rence 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

- 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 impres-sionnante 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 éga-lement 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 impor-tants, 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