D2.1´Etat de l`art sur les supports d`exécution pour

D2.1 ´ Etat de l’art sur les supports
d’ex´ecution pour environnements
petascales
VERSION 1.0
DATE 2010
EDITORIAL MANAGER Sylvain Peyronnet
AUTHORS STAFF Camille Coti, Elisabeth Brunet, Thomas Herault, Sylvain Peyronnet
Copyright ANR SPADES. 08-ANR-SEGI-025.

D2.1 ´ Etat de l’art sur les supports d’excution pour environnements petascales
Contents
1 Introduction 4
2´ Etat de l’art 5
2.1 Environnementsparall`eles.................................... 5
2.1.1 OpenMP ......................................... 5
2.1.2 Thread Building Blocks(TBB).............................. 6
2.2 Environnementsdistribu´es.................................... 8
2.2.1 MPICH2 ......................................... 8
2.2.2 OpenMPI......................................... 8
2.2.3 HARNESS ........................................ 9
2.2.4 KAAPI/TakTuk ..................................... 10
2.2.5 MRNet .......................................... 10
2.3 Environnementshybrides .................................... 11
2.3.1 UPC/GASNet ...................................... 12
2.3.2 PM2............................................ 12
2.3.3 LasuiteCHARM++................................... 13
3 Conclusion 16
ANR SPADES. 08-ANR-SEGI-025 Page 3

D2.1 ´ Etat de l’art sur les supports d’excution pour environnements petascales
Chapter 1
Introduction
L’environnement d’ex´ecution, aussi appel´e runtime environment, est un ´el´ement essentiel dans les ar-
chitectures de type grappes de machines, grands calculateurs et grilles. Son rˆole consiste `a interfacer
l’ensemble des ressources physiques d’une machine – qu’elles soient locales ou distantes – afin que les
applications s’y ex´ecutant soient en mesure de profiter de toute la puissance possible et ce, de mani`ere
transparente.
Id´ealement, un environnement d’ex´ecution propose donc, d’un point de vue local, une unification
de l’environnement pour que chacune des fonctions soit ex´ecut´eee de la mani`ere la plus adapt´eee `a
l’ensemble des ressources; d’un point de vue distant, un syst`eme de communication efficace qui per-
mettent d’´echanger donn´ees, informations et ordres aux diff´erentes ressources distantes `a travers des
communications de types point-`a-point ou de diffusion.
Une d´efinition des services rendus par l’environnement d’ex´ecution `a l’application a ´et´e ´etablie
dans [20]. On peut citer les fonctions principales : lancement de l’application sur les nœuds de calcul
(bien que cette tˆache peut ˆetre d´el´egu´ee `a une application tiers sp´ecialis´ee, l’environnement d’ex´ecution
doit ˆetre interfac´e avec cette application), mettre en relation les processus de l’application les uns avec
les autres (´echange des informations de contact), transf´erer les entr´ees/sorties et les signaux, assurer un
monitoring des processus et des ressources (que ce soit binaire, du type “processus lanc´e” vs “processus
mort”, ou donnant des informations plus pr´ecises comme la charge CPU, etc)
Que ce soit au sein d’un nœud ou d’une plateforme distribu´ee, un environnement d’ex´ecution id´eeal
doit ´egalement ˆetre capable de pallier aux pannes ´eventuelles. Cela passe par la collection d’informations
sur les diff´erentes ressources afin d’´etablir (si possible) un ´etat global de la machine et ainsi de maintenir
la coh´erence de perception des ressources (en en d´esactivant/ajoutant certaines, le cas ´ech´eant).
Nombre de travaux se sont pench´es sur l’´elaboration de telles solutions. Cependant, aucun ne propose
de solution r´epondant enti`erement `a ce cahier des charges. Nous verrons donc comment certains se
combinent.
L’objectif de la tˆache 2 intitul´ee Runtime pour architecture Petascale ´etant de concevoir un envi-
ronnement d’ex´ecution passant `a l’´echelle et tol´erant aux pannes, nous allons ici ´etudier les runtimes
majeurs actuellement propos´es et mettre en ´evidence l’environnement d’ex´ecution le plus adapt´e `a une
telle ´evolution.
ANR SPADES. 08-ANR-SEGI-025 Page 4

D2.1 ´ Etat de l’art sur les supports d’excution pour environnements petascales
Chapter 2
´
Etat de l’art
Il s’agit d’´etudier les principes fondamentaux des runtimes, leur architecture, d’extraire leurs composants,
d’´etudier l’impl´ementation de ces derniers et leur syst`eme de communication. Cet ´etat de l’art doit
produire une sorte de sp´ecification des principes et des m´ecanismes utilis´es dans les runtimes pour les
applications parall`eles. On ´etudiera particuli`erement ces principes et ces m´ecanismes sous l’angle de
l’extensibilit´e et de la tol´erance aux d´efaillances.
Les runtimes actuels n’ont pas tous la mˆeme port´ee. Certains s’attachent `a r´epartir la charge de
travail sur l’ensemble des processeurs d’une mˆeme machine, c’est ce qu’on appelle ici les environnements
parall`eles. D’autres sont plus orient´es sur le d´eploiement sur des machines distantes, appel´es ici envri-
onnements distribu´es. Un derni`ere cat´egorie s’attaquent aux deux fronts par combinaison de techniques
ici nomm´es environnements hybrides.
2.1 Environnements parall`eles
Avec l’expansion des processeurs multicœurs, il est de premi`ere importance de savoir extraire un max-
imum de parall´elisme (parall´elisme `a grain fin) d’une application de mani`ere `a utiliser efficacement
l’ensemble les processeurs.
2.1.1 OpenMP
Le standard OpenMP [38] d´efinit un ensemble d’annotations pour la parall´elisation de programmes
s´equentiels. L’annotation de certaines portions de code ´ecrites de mani`ere s´equentielle g´en`ere des sous-
tˆaches qui vont alors pouvoir s’ex´ecuter en parall`ele sur la machine `a travers l’utilisation de threads. C’est
ce qu’on appelle une approche Fork/Join : le processus invocant la section parall`ele cr´ee les threads (fork)
et attent leur terminaision avant de continuer son ex´ecution (join). L’illustration typique porte sur la
parall´elisation d’une boucle (voir Figure 2.1): en l’annotant, les it´erations du corps de boucle vont ˆetre
r´eparties et ex´ecut´ees par diff´erents threads. Le nombre de threads maximum est fix´e par l’utilisateur
grˆace une variable d’environnement.
Plusieurs impl´ementations de ce standard sont propos´ees comme GOMP [23] de GNU, Sun Studio
Compiler [47] de Sun Microsystems, OpenMP PGI Compiler [41]. Question scalabilit´e, les performances
de chacune de ces impl´ementations sont principalement d´ependantes de celles des biblioth`eques de threads
sur lesquelles elles reposent. [Le syst`eme de threads de GNU/Linux est scalable car il fait attention `a
la localit´e de ses threads : chaque processeur cr´ee les threads g´en´er´es par ce qu’il ex´ecute et les placent
en local, l’ordonnancement est fait `a partir de cette mˆeme file en local avant d’aller plus loin dans la
machine et faire du vol de travail. Il n’y a pas de syst`eme centralis´e.] En g´en´eral, chaque impl´ementation
d’OpenMP d´eveloppe sa propre biblioth`eque de threads de niveau utilisateur de mani`ere `a garder le
contrˆole sur l’ordonnancement qui est fait. Les plus “intelligents” utilisent le principe de vol de travail
comme celui fait dans GNU/Linux. Par contre, la plupart ne prenne pas en compte des param`etres
ANR SPADES. 08-ANR-SEGI-025 Page 5