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

D2.1 État de l’art sur les supports
d’exécution pour environnements
petascales
VERSION
DATE
EDITORIAL MANAGER
AUTHORS STAFF
Copyright
1.0
2010
Sylvain Peyronnet
Camille Coti, Elisabeth Brunet, Thomas Herault, Sylvain Peyronnet
ANR SPADES. 08-ANR-SEGI-025.
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Contents
1 Introduction
2 État de l’art
2.1 Environnements parallèles . . . . . .
2.1.1 OpenMP . . . . . . . . . . .
2.1.2 Thread Building Blocks(TBB)
2.2 Environnements distribués . . . . . .
2.2.1 MPICH2 . . . . . . . . . . .
2.2.2 OpenMPI . . . . . . . . . . .
2.2.3 HARNESS . . . . . . . . . .
2.2.4 KAAPI/TakTuk . . . . . . .
2.2.5 MRNet . . . . . . . . . . . .
2.3 Environnements hybrides . . . . . .
2.3.1 UPC/GASNet . . . . . . . .
2.3.2 PM2 . . . . . . . . . . . . . .
2.3.3 La suite CHARM++ . . . . .
3 Conclusion
ANR SPADES. 08-ANR-SEGI-025
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
8
8
8
9
10
10
11
12
12
13
16
Page 3
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Chapter 1
Introduction
L’environnement d’exécution, aussi appelé runtime environment, est un élément essentiel dans les architectures de type grappes de machines, grands calculateurs et grilles. Son rôle consiste à interfacer
l’ensemble des ressources physiques d’une machine – qu’elles soient locales ou distantes – afin que les
applications s’y exécutant soient en mesure de profiter de toute la puissance possible et ce, de manière
transparente.
Idéalement, un environnement d’exécution propose donc, d’un point de vue local, une unification
de l’environnement pour que chacune des fonctions soit exécutéee de la manière la plus adaptéee à
l’ensemble des ressources; d’un point de vue distant, un système de communication efficace qui permettent d’échanger données, informations et ordres aux différentes ressources distantes à travers des
communications de types point-à-point ou de diffusion.
Une définition des services rendus par l’environnement d’exécution à l’application a été établie
dans [20]. On peut citer les fonctions principales : lancement de l’application sur les nœuds de calcul
(bien que cette tâche peut être déléguée à une application tiers spécialisée, l’environnement d’exécution
doit être interfacé avec cette application), mettre en relation les processus de l’application les uns avec
les autres (échange des informations de contact), transférer les entrées/sorties et les signaux, assurer un
monitoring des processus et des ressources (que ce soit binaire, du type “processus lancé” vs “processus
mort”, ou donnant des informations plus précises comme la charge CPU, etc)
Que ce soit au sein d’un nœud ou d’une plateforme distribuée, un environnement d’exécution idéeal
doit également être capable de pallier aux pannes éventuelles. Cela passe par la collection d’informations
sur les différentes ressources afin d’établir (si possible) un état global de la machine et ainsi de maintenir
la cohérence de perception des ressources (en en désactivant/ajoutant certaines, le cas échéant).
Nombre de travaux se sont penchés sur l’élaboration de telles solutions. Cependant, aucun ne propose
de solution répondant entièrement à ce cahier des charges. Nous verrons donc comment certains se
combinent.
L’objectif de la tâche 2 intitulée Runtime pour architecture Petascale étant de concevoir un environnement d’exécution passant à l’échelle et tolérant aux pannes, nous allons ici étudier les runtimes
majeurs actuellement proposés et mettre en évidence l’environnement d’exécution le plus adapté à une
telle évolution.
ANR SPADES. 08-ANR-SEGI-025
Page 4
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Chapter 2
État de l’art
Il s’agit d’étudier les principes fondamentaux des runtimes, leur architecture, d’extraire leurs composants,
d’étudier l’implémentation de ces derniers et leur système de communication. Cet état de l’art doit
produire une sorte de spécification des principes et des mécanismes utilisés dans les runtimes pour les
applications parallèles. On étudiera particulièrement ces principes et ces mécanismes sous l’angle de
l’extensibilité et de la tolérance aux défaillances.
Les runtimes actuels n’ont pas tous la même portée. Certains s’attachent à répartir la charge de
travail sur l’ensemble des processeurs d’une même machine, c’est ce qu’on appelle ici les environnements
parallèles. D’autres sont plus orientés sur le déploiement sur des machines distantes, appelés ici envrionnements distribués. Un dernière catégorie s’attaquent aux deux fronts par combinaison de techniques
ici nommés environnements hybrides.
2.1
Environnements parallèles
Avec l’expansion des processeurs multicœurs, il est de première importance de savoir extraire un maximum de parallélisme (parallélisme à grain fin) d’une application de manière à utiliser efficacement
l’ensemble les processeurs.
2.1.1
OpenMP
Le standard OpenMP [38] définit un ensemble d’annotations pour la parallélisation de programmes
séquentiels. L’annotation de certaines portions de code écrites de manière séquentielle génère des soustâches qui vont alors pouvoir s’exécuter en parallèle sur la machine à travers l’utilisation de threads. C’est
ce qu’on appelle une approche Fork/Join : le processus invocant la section parallèle crée les threads (fork)
et attent leur terminaision avant de continuer son exécution (join). L’illustration typique porte sur la
parallélisation d’une boucle (voir Figure 2.1): en l’annotant, les itérations du corps de boucle vont être
réparties et exécutées par différents threads. Le nombre de threads maximum est fixé par l’utilisateur
grâce une variable d’environnement.
Plusieurs implémentations de ce standard sont proposées comme GOMP [23] de GNU, Sun Studio
Compiler [47] de Sun Microsystems, OpenMP PGI Compiler [41]. Question scalabilité, les performances
de chacune de ces implémentations sont principalement dépendantes de celles des bibliothèques de threads
sur lesquelles elles reposent. [Le système de threads de GNU/Linux est scalable car il fait attention à
la localité de ses threads : chaque processeur crée les threads générés par ce qu’il exécute et les placent
en local, l’ordonnancement est fait à partir de cette même file en local avant d’aller plus loin dans la
machine et faire du vol de travail. Il n’y a pas de système centralisé.] En général, chaque implémentation
d’OpenMP développe sa propre bibliothèque de threads de niveau utilisateur de manière à garder le
contrôle 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 paramètres
ANR SPADES. 08-ANR-SEGI-025
Page 5
D2.1 État de l’art sur les supports d’excution pour environnements petascales
int
main (int argc, char **argv) {
...
#pragma omp parallel for
for(int i=0; i < 4; i++){
//corps de boucle
}
...
return 0;
}
Figure 2.1: Boucle séquentielle paralélisée grâce à OpenMP.
fondamentaux à l’obtention de performances dans ce type d’environnement. En effet, tous les aspects
liés au placement de threads ainsi qu’à la localité (avec ce que cela engendre en terme de contention
d’accès et de faux partage) sont primordiaux pour dans un tel contexte [26, 39]. Les ordonnanceurs
de threads n’ont en général pas à leur disposition d’outils performants qui leur permettent d’être aussi
fins [10]. Ainsi, afin que les performances des systèmes ne s’écroulent pas, les implémentations d’OpenMP
fixent en général un thread par coeur de la machine.
ForestGOMP [50] est une extension du GOMP (le runtime OpenMP de GNU). Son objectif est de
prendre en compte ce type d’information afin de faire un ordonnancement dynamique est accord avec les
affinités mémoire et la topologie de la machine.
ForestGOMP est une brique logicielle de la suite PM2 que nous allons détailler dans la Section 2.3.2
de cet état de l’art.
2.1.2
Thread Building Blocks(TBB)
TBB [29] est une bibliothèque open-source template de C++ développée par Intel qui a pour but de
faciliter l’expression du parallèlisme d’une application écrite en C++. TBB a été conu en adéquation avec
les spécificités du langage sur lequel il s’appuie afin de combiner parallélisme de tâches et parallélisme par
données. L’aspect orienté objet de C++ permet à l’utilisateur d’exprimer différentes tâches de travail
à réaliser qui pourront s’exécuter en parallèle ou successivement selon leurs inter-dépendances en les
encapsulant dans des objets C++ de différente nature. Lors de l’implémentation de ces objets/tâches,
l’utilisateur peut également exprimer l’aptitude d’une tâche à être subdivisée en plusieurs tâches. Un
constructeur spécifique doit pour cela être spécifié qui décrire comment subdiviser l’espace de données
traiter par la tâche originale en deux – et ceci de manière récursive – et générer une seconde tâche qui
se chargera du traitement de ce nouvel sous-ensemble de données. Ainsi, le traitement est parallélisé
selon un paradidme de parallélisation de données. De plus, les templates de C++ permettent de la
description généraliste de la parallélisation de structures de boucles. L’exécution de telles structures ne
va pas se traduire par la génération de threads comme le fait OpenMP mais par celle de tâches. Ainsi,
les threads ne vont ni être spécialisés dans l’exécution d’un type de tâche comme l’illustre la Figure 2.2 ni
tous assignés à la même opération sur des sous-ensemble de données du problème comme illustrés dans
la Figure 2.31 mais se voient assigner différentes tâches pour lesquelles d’autres threads pourront venir
donner main forte sur un sous-ensemble de données, comme l’illustre la Figure 2.41 . Ainsi, du point de
vue de l’utilisateur, TBB abstrait les aspects techniques relatifs aux threads au travers de ses tâches. Les
1
Figure tirée du livre [42].
08-ANR-SEGI-025
Page 6
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Figure 2.2: Parallélistaion par tâche : Une tâche est générée pour chaque opération à exécuter.
Figure 2.3: Parallélisation de données : chaque sous-ensemble de données est assigné une entité
traitante.
différentes tâches générées sont ensuite exécutées sur les directives de l’ordonnanceur de tâches qui va les
assigner aux threads qu’il aura lui-même créés. Ces derniers sont alimentés selon le principe de vol de
travail, vol qui lui-même procède selon l’approche du diviser pour régner. En effet, si aucune tâche n’est
disponible, l’ordonnanceur est alors en mesure de provoquer la division d’une tâche afin de récupérer du
travail.
Lors de la conception de TBB , une attention particulière a été portée au problème de la scalabilité.
Ainsi, de nombreaux aspects ont été pris en compte comme la synchronisation entre threads, les problèmes
de partage de données, les affinités mémoire, les défauts de cache, etc. En partique, l’ordonnanceur de
tâches de TBB est basé sur l’agorithme de vol de travail de Cilk [6] qui utilise un système de queues sans
verrou, des primitives de synchronisation atomique ont été mises en avant et un allocateur de mémoire
passant à l’échelle est développé afin de privilégier les affinités aux niveaux des caches et limiter les
contentions.
Figure 2.4: Combinaison de parallélisation : les tâches sont subdivisées en plusieurs sousensemble le cas échéant.
08-ANR-SEGI-025
Page 7
D2.1 État de l’art sur les supports d’excution pour environnements petascales
2.2
Environnements distribués
Dans le contexte des grappes et grilles de calcul, la problématique de déploiement des applications parallèles ne se focalise plus sur l’utilisation de chaque unité de calcul d’une machine mais sur l’utilisation
de toutes les machines de l’environnement. L’échelle de parallélisme considérée dans ce type de support d’exécution monte d’un niveau. L’exécution d’une application se déroule alors au travers de celle
de plusieurs processus totalement indépendants qui sont ordonnancés en parallèle sur des ressources
distantes via un environnement d’exécution distribué.
2.2.1
MPICH2
L’environnement d’exécution de MPICH2 [24] est MPD [12]. Il s’agit d’un ensemble de démons
s’exécutant en permanence sur les nœuds de calcul. Lorsqu’une application MPI est démarrée, les
démons MPD créent un nouveau processus sur chaque nœud impliqué, appelé PM (Process Manager ).
Ces processus créent une instance de l’environnement d’exécution de l’application. Les démons MPD,
eux, sont partagés entre les multiples applications exécutées, et sont persistents.
MPD a été conçu dans une optique de simplicité afin d’être potentiellement exécuté par le superutilisateur des machines. C’est pourquoi certains choix techniques ont été faits dans ce sens.
Les démons sont interconnectés selon une topologie en anneau, non scalable. C’est acceptable jusqu’à
quelques dizaines de processus, au-delà les performances s’en ressentent fortement. Ce choix a été fait
dans le cadre de cet objectif de simplicité. À l’époque où MPD a été conçu, c’était une limite raisonnable
: tous les utilisateurs n’avaient pas de clusters composés de milliers de nœuds, et les super-calculateurs
composés de plusieurs dizaines de milliers de nœuds utilisent un lanceur dédié, spécialisé pour la machine.
Aujourd’hui, cette option n’est plus raisonnable.
MPD tolère les défaillances dans le sens où l’ensemble des démons ne meurent pas en cas de mort
d’un démon. L’anneau est reconstruit en établisssant une connexion entre les deux voisins du démon
mort. On réduit ainsi la taille du système, mais il n’est pas possible d’ajouter de nouveaux démons dans
l’anneau.
ADI 3 (Abstract Device Interface)
CH3
Channel
SOCK
(TCP socket)
SHMEM
RDMA
Système d'exploitation
Figure 2.5: Architecture de MPICH2
2.2.2
OpenMPI
L’environnement d’exécution d’OpenMPI [21] est appelé ORTE [13]. Il est composé d’un ensemble de
démons s’executant sur chaque nœud impliqué dans le calcul. Deux modes d’utilisation sont disponibles
: un mode dédié, où l’environnement d’exécution est déployé pour chaque application, et un mode
persistent, où l’environnement d’exécution s’exécute en permanence et est partagé entre les multiples
applications exécutées.
08-ANR-SEGI-025
Page 8
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Tout comme le reste d’OpenMPI, ORTE est basé sur une architecture modulaire par composants [46].
Chaque fonctionnalité devant être remplie est implementée dans un framework, qui définissent une API.
Chaque façon d’implémenter cette API est implémentée dans un composant. Une instance d’un composant chargée lors de l’exécution est un module. Par exemple, le framework chargé des communications
point-à-point pour les fonctions MPI est appelé BTL (Byte Transfer Layer ). Plusieurs composants sont
disponibles pour ce framework : il existe un composant pour les réseaux TCP, un autre pour les réseaux
Myrinet (un composant pour le pilote MX, un autre composant pour le pilote GM), etc. Si plusieurs
cartes réseaux sont disponibles, plusieurs modules peuvent être utilisés en même temps. Chaque composant est compilé sous forme d’une bibliothèque à liaison dynamique, qui est chargée à l’initialisation
de l’exécution.
Cette modularité rend ORTE particulièrement facile à étendre en ajoutant des fonctionnalités. Par
exemple, le support d’un nouveau lanceur ou d’un nouveau type de cartes réseaux ne nécessite que la
ré-implémentation de l’API du framework concerné.
La modularité permet également un réglage particulièrement fin des paramètres d’OpenMPI et
d’ORTE, grâce au choix des composants utilisés et à leurs paramétrage. Des composants spécialement
orientés vers la scalabilité (plusieurs milliers de nœuds) sont disponibles pour plusieurs frameworks.
Par exemple, les communications collectives constitue une fonctionalité importante d’un environnement
d’exécution. Il existe un framework dédié, et un composant utilisant des algorithmes de communications
optimisés. Dans l’état présent, ORTE peut raisonnablement être utilisé pour des exécutions impliquant
plusieurs milliers de nœuds.
Actuellement, ORTE n’est pas tolérant aux défaillances. La comportement par défaut est d’assurer
la terminaison de l’application en tuant les autres processus. Un mécanisme de tolérance aux pannes par
prise d’état coordonnée est disponible, mais tous les processus étant relancés, il implique le redémarrage
de toute l’application, environnement d’exécution y compris.
OMPI
ORTE
OPAL
Système d'exploitation
Figure 2.6: Architecture d’OpenMPI
2.2.3
HARNESS
HARNESS est un environnement d’exécution d’ancienne génération. Plus généraliste, il est utilisé par
l’implémentation MPI FT-MPI [18, 19] et PVM [48].
Sa scalabilité repose sur la topologie interne, basée sur des arbres binomiaux utilisés pour les communications et routant les flux de données.
La topologie utilisée a des propriétés de résilience [2] lui permettant de survivre aux pannes et de
08-ANR-SEGI-025
Page 9
D2.1 État de l’art sur les supports d’excution pour environnements petascales
continuer à fonctionner. Cette résilience l’a rendu particulièrement adapté à des systèmes de communications tolérants aux pannes comme FT-MPI ou PVM.
L’architecture de HARNESS n’est pas modulaire ; il est par conséquent difficile de l’étendre en lui
ajoutant des fonctionalités. De plus, le projet HARNESS et les projets l’utilisant ne sont à ce jour plus
actifs : PVM est encore maintenu mais n’est plus développé, et FT-MPI a été interrompu pour former
OpenMPI.
2.2.4
KAAPI/TakTuk
KAAPI [22] est un système d’ordonnancement de tâches sur des systèmes multi-processeurs. Les tâches
sont décrites au moyen de l’interface Athapascan, en définissant les fonctions à exécuter et les dépendances
entre les tâches. Athapascan construit alors le graphes de dépendances entre les tâches, et les ordonnances
en utilisant des algorithmes de vol de cycle.
KAAPI utilise le lanceur TakTuk [35] comme environnement d’exécution “rudimentaire” et la bibliothèque de communications Inuktitut [34]. TakTuk permet notamment de lancer l’application en
parallèle, mais aussi de transférer des fichiers (par exemple, les fichiers de données) et de compiler
l’application sur les machines cible. Cette dernière fonctionnalité s’avère particulièrement utile dans des
environnements hétérogènes comme les grilles, qui constituent une cible importante de KAAPI.
TakTuk est un outil qui a pour vocation de déployer des commandes en parallèles sur un ensemble de
ressources distantes. Basé sur un algorithme adaptatif de vol de cycles, il s’auto-déploie et met en place
une infrastructure de communication qui sera utilisée pour propager les commandes et les données. Il peut
propager une commande, copier un fichier, effectuer des communications le long de cette infrastructure
et du multiplexage/démultiplexage d’entrées-sorties. L’algorithme d’adaptation sur lequel il se base tient
compte dynamiquement des performances des machines et des interconnexions et de la charge de travail
sur chacune des ressources.
TakTuk peut s’auto-déployer sur des machines où il n’est pas installé. Une fois l’infrastructure
TakTuk en place, il est possible de propager des commandes entre les démons TakTuk, à la manière des
lanceurs spécialisés. TakTukComm, une bibliothèque de communications est disponible pour effectuer
des communications sur cette infrastructure.
TakTuk cible principalement les systèmes à grande échelle, potentiellement hétérogènes, comme les
grandes clusters et les grilles de calcul. Il n’est pas tolérant aux défaillances. Son architecture n’est pas
modulaire, et les choix techniques le rendent difficilement extensible. De plus, il s’agit principalement
d’un outil de propagation, et il ne remplit pas toutes les fonctions d’un environnement d’exécution. La
bibliothèque TakTukComm peut cependant permettre d’écrire une surcouche permettant de l’exploiter
comme tel, comme c’est le cas dans KAAPI.
2.2.5
MRNet
MRNet [4, 43] (Multicast/Reduction Network) est un réseau d’overlay fournissant des outils de communications pour des systèmes parallèles et distribués. Les communications se basent sur les deux primitives
de diffusion et de réductions, permettant de transférer et d’aggréger des données entre des nœuds selon
une topologie scalable. La topologie utilisée est un arbre, choisi pour ses qualités de scalabilité.
Les processus MRNet sont répartis selon une topologie d’arbre et supportent les processus de
l’application cible, qui sont situés au niveau des feuilles de l’arbre. Un processus particulier, la frontale
du réseau MRNet, déploie les autres processus MRNet et sert de point central pour les communications.
En particulier, la frontale peut initier des communications point-à-point ou collectives avec le reste de
l’application. Les communications passent par des canaux logiques ou flux, qui peuvent être montants
(des processus vers la frontale) et descendants (de la frontale vers les processus). Les processus de
l’application peuvent être groupés selon des communicateurs semblables aux communicateurs MPI : une
communication collective sur un communicateur est effectuée par tous les processus faisant partie de
ce communicateur. Comme en MPI, l’opération effectuée lors d’une réduction peut être définie par le
programmeur d’une application MRNet. Ces opérations sont appelées des filtres.
08-ANR-SEGI-025
Page 10
D2.1 État de l’art sur les supports d’excution pour environnements petascales
nutmeg:0 => c01:0 c02:0 c03:0 c04:0 ;
c03:0 => c05:0 ;
c04:0 => c06:0 c07:0 c08:0 c09:0 ;
c08:0 => c10:0 ;
c09:0 => c11:0 ;
nutmeg
|
|
------/|
|\
/ |
| \
/ |
| \
/
|
|
\
c01 c02 c03 c04
|
|
c05
|
------/ |
| \
/ |
| \
/
|
|
\
c06 c07 c08 c09
|
|
c10 c11
Figure 2.7: Exemple de topologie MRNet, décrite (à gauche) par les liens entre les nœuds.
En se basant sur une redondance de l’information inhérente dans les processus de l’arbre, MRNet
établit une structure de données cohérentes (la cohérence est caractérisée comme “faible”, c’est-à-dire
que plusieurs copies de chaque donnée existent dans le système avec différents niveaux de cohérence)
permettant de rétablir la structure de l’arbre MRNet en cas de défaillance. La localité des données
redondées dans les processus survivants assure une limitation du nombre de processus impliqués dans
le réablissement de la structure après une défaillance. Le modèle de rétablissement sur défaillance de
MRNet est appelé “compensation d’état” (state compensation) [3].
La topologie de l’arbre peut être décrite dans un fichier en décrivant les liens entre les nœuds MRNet ;
il ne s’agit pas forcément d’un arbre binomial ou de Fibonacci. Un exemple de topologie et sa description
est donné figure 2.7. Cette fonctionalité permet à MRNet de s’adapter à des topologies non uniformes,
comme les clusters de clusters. Ses performances et sa scalabilité en font un bon candidat pour lancer des
outils comme des démons de monitoring et aggréger les résultats, notamment grâce à des fonctionnalités
de transferts de fichiers en mode zéro-copie.
MRNet est une bibliothèque de communication permettant d’écrire des environnements d’exécutions
pour applications parallèles ou distribuées, et non un environnement d’exécution. Pour en obtenir un, il
faut écrire une frontale et des nœuds en utilisant les fonctions de cette bibliothèque. Ce n’est pas une
bibliothèque de communications complète dans le sens o ses communications ne sont pas aussi flexibles
que celles d’une bibliothèque de communications point-à-point comme MPI. Par exemple, elles ont lieu
exclusivement entre la frontale et un processus feuille. L’API MRNet ne permet pas d’établir de flux
entre deux processus feuille. De même, les opérations collectives (diffusion et réduction) peuvent avoir
pour racine exclusivement la frontale MRNet. Enfin, MRNet ne fournit pas de méthode de lancement
: l’arbre MRNet doit être déployé par un système externe, ce qui est possible avec SSH ou RSH dans
les environnement simples, mais peut devenir non-trivial dans un environnement nécessitant l’utilisation
d’un ordonnanceur de tâches. MRNet ne fournit pas de moyen de s’interfacer avec les systèmes de
lancement.
2.3
Environnements hybrides
L’augmentation massive du nombre de cœurs engendre de nouvelles problématiques. Lorsqu’une application écrite selon un paradigme de programmation distribué est exécutée sur un ensemble de machine,
l’utilisateur produit généralement un schéma de placement classique de manière à associer une instance
08-ANR-SEGI-025
Page 11
D2.1 État de l’art sur les supports d’excution pour environnements petascales
à une ressource de calcul. Ainsi, une exécution dimensionnée pour une plate-forme massive peut alors se
voir repliée sur un sous ensemble, voire même sur un même nœud. La cohabitation de tant d’instances
sur une même machine entrane de nombreux effets de bords sur l’accès aux différentes ressources mais
également en terme de consommation mémoire. Afin de limiter ce genre de phénomènes, des approches
de programmation hybride sont développées qui mèlent programmation distribuée et programmation
parallèle. Une instance de l’application qui à présent parallélisée au travers de d’outils tels qu’OpenMP,
TBB, etc. Cela permet non seulement de préserver les ressources mais aussi de produire un grain de
parallélisme plus adapté à l’application considérée.
2.3.1
UPC/GASNet
L’implémentation de UPC développée à Berkeley [28] utilise l’infrastructure de communications GASNet [7] comme environnement d’exécution et de communication. GASNet est également utilisé par les
langages de programmation à espace d’adressage partitionné Titanium [25] (Java) et l’implémentation
du Laboratoire National de Los Alamos de Co-Array Fortran [15].
Une tentative d’utilisation de MPI comme environnement de communication a été effectuée [9],
utilisant alors les routines MPI pour les accès à la mémoire distante et l’environnement d’exécution
de l’implémentation MPI comme environnement d’exécution, par héritage de la couche MPI. Cet essai
n’a pas été concluant, montrant le fait que le paradigme MPI n’est pas adapté pour des opération
RDMA comme les accès à des zones mémoire distantes de type push et pull nécessaires aux langages
de programmation à espace d’adressage partitionné comme UPC.
Une étude comparative utilisant plusieurs applications et comparant leur implémentation en MPI et
UPC a montré une meilleure scalabilité des applications UPC [17], la plupart du temps du fait de la
meilleure connaissance de la localité des donnés fournies par UPC. Cependant, les opérations collectives
n’étant pas le propos de UPC, elles sont pour le moment implémentées de façon naı̈ve et non sclalable.
GASNet est extensible dans le sens où il peut être porté sur d’autres types de réseaux. Son architecture sépare distinctement la couche transport, qui implémente les communications sur un type de réseau
donné, des fonctionnalités de l’interface GASNet. Pour le porter sur un nouveau type de réseaux, il suffit
de réimplémenter cette couche de communications. Les couches supérieures ne sont pas modulaires. Il
n’inclut pas de fonctionalités relatives à la tolérance aux défaillances.
2.3.2
PM2
La suite logicielle PM2 [37] est constituée de plusieurs briques, comme l’illustre la Figure 2.8. Comme cité
dans la Section 2.1.1, la partie parallèle de cet environnement d’exécution est assurée car ForestGOMP,
tandis que la partie distribuée est obtenue par NewMadeleine au travers de MPICH2.
ForestGOMP s’appuie sur l’ordonnanceur de threads Marcel [16] afin de tirer parti des ressources de
calcul disponibles. En effet, pour accélérer l’éxécution d’une application sur une machine hiérarchique,
Marcel dispose dún ensemble fonctionnalités supplémentaires, dénommé BubbleSched [49] permettant de
modéliser la machine, et de structurer l’ensemble des threads de l’application suivant certains paramètres
(suivant des affinités mémoire, par exemple). Ainsi, le compilateur OpenMP de GNU a été modifié de
manière à ce qu’il génère une hiérarchie de bulles Marcel suivant l’arbre décrit par les annotations, et
non plus une hiérarchie de thread POSIX. De cette façon, une hiérarchie d’entités ordonnancables par
Marcel de manière adaptée est obtenue. A la manière de l’ordonnaceur de threads GNU/Linux, Marcel a
été conçu avec des perspectives de scalabilité. Les files de threads prêts sont localisées par processeur, la
création de thread est réalisée localement et l’ordonnanceur ne cherche à ordonnancer que les threads qui
lui sont rattachés tant que la charge est suffisante afin de ne pas provoquer de contention. Les aspects
de tolérance aux pannes ne sont pas traités.
La partie communication de PM2 est assurée par NewMadeleine [11] qui est une bibliothèque de
communication qui a pour vocation d’appliquer des stratégies d’ordonnancement sur l’ensemble des
communication en concurrence sur une machine, et ce de manière dynamique. La portée de ce travail
sur des plate-formes de grande envergure est réalisée au travers du portage qui a été réalisé de MPICH2
08-ANR-SEGI-025
Page 12
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Figure 2.8: Architecture de la suite PM2
sur NewMadeleine [36]. Ainsi, les critères de scalabilité et de tolérances aux pannes sont héritées de
MPICH2 (voir Section 2.2.1).
2.3.3
La suite CHARM++
La suite CHARM++ (voir Figure 2.9) est développée au sein du projet PPL (Parallel Programming
Laboratory) du département d’informatique de l’Université d’Urbana-Champaign. C’est un projet de
long terme : l’article fondateur de CHARM++ [32] date de 1993 et est toujours actif. Charm++
est utilisé comme runtime pour plusieurs applications significatives telles que NMAD [40], ou encore
OpenAtom [51] sur des plate-formes d’envergure [5, 8].
Charm++ [31] a un modèle de programmation qui privilégie le parallélisme de tâches. En effet, une
même application va être divisée en plusieurs opérations, liées les unes aux autres au travers d’un graphe
de dépendances. Ceci est une approche qui diffère de celle traditionnellement employée dans les applications MPI où l’application est scindée en sous domaines qui sont traités au sein de processus indépendants
en parallèle. Chaque tâche est encapsulée dans un objet Charm++ (aussi appelé chare) écrits en C++
et qui a l’avantage de pouvoir migrer sur l’ensemble des ressources de la machine en vue de faire de
l’équilibrage de charge. Plusieurs politiques d’équilibrage de charge ont été conçues afin d’exploiter au
mieux les ressources disponibles. Certaines [45] sont basées sur des approches centralisées très efficaces
pour un nombre de processeurs limité car elles deviennent rapidement des goulots d’étranglement. Les
politiques distribuées enlèvent le problème de goulot d’étranglement mais ont de piètre performance.
Avec des solutions hybrides, basées sur une approche hiérarchique, Charm++ arrive à passer à l’échelle
sur un nombre très important de processeurs [52]. De plus, les affinités de chares avec les ressources de
communication peuvent être prises en compte dans l’ordonnnancement afin de limiter les contentions et
donc améliorer encore les performances [1, 33].
AMPI(Adaptive MPI ) [27], sur-couche de Charm++, permet d’exécuter des applications qui suivent
le paradigme de programmation de MPI au sein de Charm++. Après quelques modifications néanmoins
(pas de variables globales, par exemple), chaque processus d’une application MPI qui aurait été lancé
dans une configuration classique est encapsulé dans un objet Charm++ sous le forme d’un thread de
niveau utilisateur. Ces threads sont également migrables, toujours dans l’optique d’équilibrer la charge
08-ANR-SEGI-025
Page 13
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Figure 2.9: Architecture de la suite CHARM++
sur l’ensemble des ressources de calcul.
CONVERSE [30] est la brique de base de la suite. Il fait l’interface avec les ressources de calcul
et les ressources réseaux. Une instance de Converse est initialisée par cœur de processeur grâce à
un lanceur qui diffère selon les environnements. Si la couche de communication bas-niveau est une
implémentation de MPI, le lanceur associé (appel à mpiexec) va être utilisé afin d’initialiser –en même
temps que l’environnement de communication – l’instance de Converse, qui elle-même initialise la pile
Charm++. De même, avec le lanceur de PVM, etc. Dans ce cas, nous nous retrouvons avec les contraintes
liées aux implémentations et citées aux sections précédentes (cf. Sections 2.2.1 et 2.2.2). Dans le cas
contraire, les instances peuvent être lancées via l’utilitaire qui se connecte à chaque nœud via rsh, récolte
toutes les informations avant de les redistribuer et démarrer les instances de Converse (le protocole est
illustré à la Figure 2.10).
Par ailleurs, la suite Charm++ propose plusieurs mécanismes de tolérance aux pannes :
• la méthode classique du checkpoint/restart. Elle permet de sauvegarder l’état de l’exécution de
l’application sur chaque machine au travers de fichiers stockés sur un serveur central. En cas de
défaillance, l’application est ainsi redémarrée à partir du dernier point de sauvegarde effectué.
• FTC-Charm++ est un procédé amélioré o les checkpoints sont stockés en local dans l’espace
mémoire temporaire scratch des machines. Cela a l’avantage de permettre une reprise plus rapide
et de ne pas imposer l’utilisation d’un serveur central qui doit se comporter de manière infaillible
pour que le système fonctionne. FTC-Charm++ a également l’avantage de reprendre l’exécution
sur une nombre déséquilibré de ressources dans le cas o il n’était pas possible de les remplacer [53].
• FTL-Charm++ est un protocole de tolérance aux fautes à enregistrement de messages pessimiste.
Chaque objet va logguer les messages qu’il envoie dans la mémoire locale.
08-ANR-SEGI-025
Page 14
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Figure 2.10: Prototype du lanceur de Charm++
• Proactive Fault Tolerance [44, 14] permet de faire de la prédiction de pannes. Basé sur l’observation
de la machine, le système réagit en migrant les objets sur une ressource en voie de devenir défaillant
sur des ressources saines. L’ensemble des ressources sont inventoriées au travers d’un arbre qui
est remodelé à partir de ces prédictions et permet de maintenir l’exécution de l’application sur
l’ensemble des ressources restantes.
08-ANR-SEGI-025
Page 15
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Chapter 3
Conclusion
Modèle de programmation Extensibilité Tolérance aux pannes
OpenMP
parallèle
oui
non
TBB
parallèle
oui
non
MPICH2
distribué
non
non
OpenMPI
distribué
oui
oui
KAAPI/TakTuk
distribué
non
non
MRNet
distribué
non
oui
UPC/GASNet
hybride
non
non
PM2
hybride
non
non
Charm++
hybride
oui
oui
Aucune des solutions étudiées dans ce document ne répond totalement au cahier des charges entrepris.
Plusieurs approches apportent des éléments de réponse avec des implémentations plus ou moins matures.
Il est également à noter que nous avons ici étudier des environnements d’exécution de différents niveaux
dont les architectures cibles, les paradigmes employés, les niveaux d’optimisation d’exploitation sont
eux-mêmes différents. Ainsi, même si tous ces concepts ne peuvent raisonnablement pas se regrouper au
sein d’un seul et unique environnement d’exécution idéal, il est néanmoins primordial de les étudier afin
d’en tirer des concepts qui pourraient se révéler fondamentaux par la suite. Ainsi, nous allons à présent
nous focaliser sur trois environnements afin d’étudier en détail leur profil réél : ORTE, HARNESS et
CHARM++.
ANR SPADES. 08-ANR-SEGI-025
Page 16
D2.1 État de l’art sur les supports d’excution pour environnements petascales
Bibliography
[1] Tarun Agarwal, Amit Sharma, and Laxmikant V. Kalé. Topology-aware task mapping for reducing
communication contention on large parallel machines. In Proceedings of IEEE International Parallel
and Distributed Processing Symposium 2006, April 2006.
[2] Thara Angskun, George Bosilca, and Jack Dongarra. Binomial graph: A scalable and fault-tolerant
logical network topology. In Ivan Stojmenovic, Ruppa K. Thulasiram, Laurence Tianruo Yang,
Weijia Jia, Minyi Guo, and Rodrigo Fernandes de Mello, editors, Parallel and Distributed Processing
and Applications, 5th International Symposium, ISPA 2007, Niagara Falls, Canada, August 29-31,
2007, Proceedings, volume 4742 of Lecture Notes in Computer Science, pages 471–482. Springer,
2007.
[3] Dorian C. Arnold and Barton P. Miller. A scalable failure recovery model for tree-based overlay
networks. (TR1626).
[4] Dorian C. Arnold, G. D. Pack, and Barton P. Miller. Tree-based overlay networks for scalable
applications. In IPDPS. IEEE, 2006.
[5] Abhinav Bhatele, Sameer Kumar, Chao Mei, James C. Phillips, Gengbin Zheng, and Laxmikant V.
Kale. NAMD: A Portable and Highly Scalable Program for Biomolecular Simulations. Technical
Report UIUCDCS-R-2009-3034, Department of Computer Science, University of Illinois at UrbanaChampaign, February 2009.
[6] Robert D. Blumofe, Christopher F. Joerg, Bradley C. Kuszmaul, Charles E. Leiserson, Keith H.
Randall, and Yuli Zhou. Cilk: An efficient multithreaded runtime system. In Journal of Parallel
and Distributed Computing, pages 207–216, 1995.
[7] Dan Boachea. D. bonachea gasnet specification, v1.1. Technical Report UCB/CSD-02-1207, U.C.
Berkeley, 2002.
[8] Eric Bohm, Abhinav Bhatele, Laxmikant V. Kale, Mark E. Tuckerman, Sameer Kumar, John A.
Gunnels, and Glenn J. Martyna. Fine Grained Parallelization of the Car-Parrinello ab initio MD
Method on Blue Gene/L. IBM Journal of Research and Development: Applications of Massively
Parallel Systems, 52(1/2):159–174, 2008.
[9] Dan Bonachea and Jason Duell. Problems with using MPI 1.1 and 2.0 as compilation targets for
parallel language implementations. IJHPCN, 1(1/2/3):91–99, 2004.
[10] François Broquedis.
De l’exécution structurée de programmes openmp sur architectures
hiérarchiques. Mémoire de dea, Université Bordeaux 1, June 2007.
[11] Elisabeth Brunet. Une approche dynamique pour l’optimisation des communications concurrentes
sur réseaux haute performance. PhD thesis, Université Bordeaux 1, 351 cours de la Libération —
33405 TALENCE cedex, December 2008.
[12] R. Butler, W. Gropp, and E. Lusk. A scalable process-management environment for parallel programs. In Jack Dongarra, Péter Kacsuk, and Norbert Podhorszki, editors, Recent Advances in Parallel Virtual Machine and Message Passing Interface, 7th European PVM/MPI Users’ Group Meeting,
Balatonfüred, Hungary, September 2000, Proceedings, volume 1908, pages 168–175. Springer, 2000.
ANR SPADES. 08-ANR-SEGI-025
Page 17
D2.1 État de l’art sur les supports d’excution pour environnements petascales
[13] Ralph H. Castain, Timothy S. Woodall, David J. Daniel, Jeffrey M. Squyres, Brian Barrett, and
Graham E. Fagg. The open run-time environment (openRTE): A transparent multi-cluster environment for high-performance computing. In Beniamino Di Martino, Dieter Kranzlmüller, and Jack
Dongarra, editors, Recent Advances in Parallel Virtual Machine and Message Passing Interface, 12th
European PVM/MPI Users’ Group Meeting, Sorrento, Italy, September 18-21, 2005, Proceedings,
volume 3666 of Lecture Notes in Computer Science, pages 225–232. Springer, 2005.
[14] Sayantan Chakravorty, Celso L. Mendes, and Laxmikant V. Kalé. Proactive fault tolerance in mpi
applications via task migration. In HiPC, volume 4297 of Lecture Notes in Computer Science, pages
485–496. Springer, 2006.
[15] C. Cristian Coarfa, Yuri Dotsenko, John Mellor-Crummey, Daniel Chavarria-Miranda, Francois
Cantonnet, Tarek El-Ghazawi, Ashrujit Mohanti, and Yiyi Yao. An evaluation of global address
space languages: Co-array fortran and unified parallel. Technical report, Chicago, Illinois, June
2005.
[16] Vincent Danjean. Contribution à l’élaboration d’ordonnanceurs de processus légers performants et
portables pour architectures multiprocesseurs. PhD thesis, École normale supérieure de Lyon, 46,
allée d’Italie, 69364 Lyon cedex 07, France, December 2004. 156 pages.
[17] Tarek A. El-Ghazawi, François Cantonnet, Yiyi Yao, Smita Annareddy, and Ahmed S. Mohamed.
Benchmarking parallel compilers: A upc case study. Future Generation Comp. Syst., 22(7):764–775,
2006.
[18] Graham E. Fagg and Jack Dongarra. FT-MPI: Fault tolerant MPI, supporting dynamic applications
in a dynamic world. In Jack Dongarra, Péter Kacsuk, and Norbert Podhorszki, editors, Recent
Advances in Parallel Virtual Machine and Message Passing Interface, 7th European PVM/MPI
Users’ Group Meeting, Balatonfüred, Hungary, September 2000, Proceedings, volume 1908 of Lecture
Notes in Computer Science, pages 346–353. Springer, 2000.
[19] Graham E. Fagg and Jack J. Dongarra. HARNESS fault tolerant MPI design, usage and performance
issues. Future Generation Computer Systems, 18(8):1127–1142, October 2002.
[20] Geoffrey Fox, Sanjay Ranka, Michael L. Scott, Allen D. Malony, James C. Browne, Marina C. Chen,
Alok N. Choudhary, Thomas Cheatham, Janice E. Cuny, Rudolf Eigenmann, Amr F. Fahmy, Ian T.
Foster, Dennis Gannon, Tomasz Haupt, Carl Kesselman, Charles Koelbel, Wei Li, Monica S. Lam,
Thomas J. LeBlanc, Jim Openshaw, David A. Padua, Constantine D. Polychronopoulos, Joel H.
Saltz, Alan Sussman, Gil Weigand, and Katherine A. Yelick. Common runtime support for high
performance parallel languages. In Proceedings of the Supercomputing ’93 Conference, pages 752–
757, 1993.
[21] Edgar Gabriel, Graham E. Fagg, George Bosilca, Thara Angskun, Jack J. Dongarra, Jeffrey M.
Squyres, Vishal Sahay, Prabhanjan Kambadur, Brian Barrett, Andrew Lumsdaine, Ralph H. Castain, David J. Daniel, Richard L. Graham, and Timothy S. Woodall. Open MPI: Goals, concept,
and design of a next generation MPI implementation. In Proceedings, 11th European PVM/MPI
Users’ Group Meeting, pages 97–104, Budapest, Hungary, September 2004.
[22] Thierry Gautier, Xavier Besseron, and Laurent Pigeon. KAAPI: A thread scheduling runtime system
for data flow computations on cluster of multi-processors. In Marc Moreno Maza and Stephen M.
Watt, editors, Parallel Symbolic Computation, PASCO 2007, International Workshop, 27-28 July
2007, University of Western Ontario, London, Ontario, Canada, pages 15–23. ACM, 2007.
[23] GOMP. An OpenMP implementation for GCC. http://gcc.gnu.org/projects/gomp.
[24] W. Gropp and E. Lusk. The MPI communication library: its design and a portable implementation.
In Proceedings of the Scalable Parallel Libraries Conference, October 6–8, 1993, Mississippi State,
Mississippi, pages 160–165, 1109 Spring Street, Suite 300, Silver Spring, MD 20910, USA, October
1994. IEEE Computer Society Press.
08-ANR-SEGI-025
Page 18
D2.1 État de l’art sur les supports d’excution pour environnements petascales
[25] P. Hilfinger, D. Bonachea, K. Datta, D. Gay, S. Graham, B. Liblit, G. Pike, J. Su, and K. Yelick.
Titanium language reference manual. (UCB/CSD-2005-15), 2005.
[26] Jay Hoeflinger, Prasad Alavilli, and Thomas Jackson. Producing scalable performance with openmp:
Experiments with two cfd applications. Parallel Computing, 27:582–593, 2000.
[27] Chao Huang, Orion Lawlor, and L. V. Kalé. Adaptive MPI. In Proceedings of the 16th International
Workshop on Languages and Compilers for Parallel Computing (LCPC 2003), LNCS 2958, pages
306–322, College Station, Texas, October 2003.
[28] Parry Husbands, Costin Iancu, and Katherine A. Yelick. A performance analysis of the berkeley
upc compiler. In ICS, pages 63–73, 2003.
[29] Intel. Tbb home page. http://www.threadingbuildingblocks.org/.
[30] L. V. Kale, Milind Bhandarkar, Narain Jagathesan, Sanjeev Krishnan, and Joshua Yelon. Converse:
An Interoperable Framework for Parallel Programming. In Proceedings of the 10th International
Parallel Processing Symposium, pages 212–217, April 1996.
[31] Laxmikant V. Kale, Eric Bohm, Celso L. Mendes, Terry Wilmarth, and Gengbin Zheng. Programming Petascale Applications with Charm++ and AMPI. In D. Bader, editor, Petascale Computing:
Algorithms and Applications, pages 421–441. Chapman & Hall / CRC Press, 2008.
[32] L.V. Kalé and S. Krishnan. CHARM++: A Portable Concurrent Object Oriented System Based
on C++. In A. Paepcke, editor, Proceedings of OOPSLA’93, pages 91–108. ACM Press, September
1993.
[33] Gregory A. Koenig and Laxmikant V. Kale. Optimizing distributed application performance using
dynamic grid topology-aware load balancing. In 21st IEEE International Parallel and Distributed
Processing Symposium, March 2007.
[34] Nhien-An Le-Khac and Euloge. Performance evaluation of INUKTITUT: An efficient interface for
asynchronous parallel programming environment athapascan. In S. Q. Zheng, editor, International
Conference on Parallel and Distributed Computing Systems (PDCS’05), pages 157–162, Phoenix,
AZ, USA, November 2005. IASTED/ACTA Press 2005.
[35] Cyrille Martin. Déploiement et contrôle d’applications parallèles sur grappes de grandes tailles,
December 15 2003.
[36] Guillaume Mercier, François Trahay, Darius Buntinas, and Elisabeth Brunet. NewMadeleine: An
Efficient Support for High-Performance Networks in MPICH2. In Proceedings of 23rd IEEE International Parallel and Distributed Processing Symposium (IPDPS’09), Rome, Italy, May 2009. IEEE
Computer Society Press.
[37] R. Namyst and J.-F. Méhaut. PM2: Parallel Multithreaded Machine; A computing environment
for distributed architectures. 1995.
[38] OpenMP. OpenMP Official Home Page. http://www.openmp.org/.
[39] Marc Pérache. Contribution à l’élaboration d’environnements de programmation dédiés au calcul
scientifique hautes performances. Thèse de doctorat, spécialité informatique, CEA/DAM Île de
France, Université de Bordeaux 1, Domaine Universitaire, 351 Cours de la libération, 33405 Talence
Cedex, October 2006. 141 pages.
[40] James C. Phillips, Rosemary Braun, Wei Wang, James Gumbart, Emad Tajkhorshid, Elizabeth
Villa, Christophe Chipot, Robert D. Skeel, Laxmikant Kalé, and Klaus Schulten. Scalable molecular
dynamics with NAMD. Journal of Computational Chemistry, 26(16):1781–1802, 2005.
[41] Portland Group. PGI Compilers and tools. http://www.pgroup.com/resources/openmp.htm.
[42] James Reinders. In Intel Threading Building Blocks. O’Reilly, 2007.
08-ANR-SEGI-025
Page 19
D2.1 État de l’art sur les supports d’excution pour environnements petascales
[43] Philip C. Roth, Dorian C. Arnold, and Barton P. Miller. MRNet: A software-based multicast/reduction network for scalable tools. In SC’2003 Conference CD, Phoenix, AZ, November
2003. IEEE/ACM SIGARCH. UWisc.
[44] Sayantan Chakravorty, Celso Mendes and L. V. Kale. Proactive fault tolerance in large systems. In
HPCRI Workshop in conjunction with HPCA 2005, 2005.
[45] A. Sinha and L.V. Kalé. A load balancing strategy for prioritized execution of tasks. In Seventh
International Parallel Processing Symposium, pages 230–237, Newport Beach, CA., April 1993.
[46] Jeffrey M. Squyres and Andrew Lumsdaine. A component architecture for LAM/MPI. In Jack
Dongarra, Domenico Laforenza, and Salvatore Orlando, editors, Recent Advances in Parallel Virtual
Machine and Message Passing Interface,10th European PVM/MPI Users’ Group Meeting, Venice,
Italy, September 29 - October 2, 2003, Proceedings, volume 2840 of Lecture Notes in Computer
Science, pages 379–387. Springer, 2003.
[47] Sun Microsystems. OpenMP API User’s Guide). http://dlc.sun.com/pdf/819-3694/819-3694.pdf.
[48] V. Sunderam. PVM: A framework for parallel distributed computing. Concurrency: Practice and
Experience, 2(4):315–339, December 1990.
[49] Samuel Thibault.
Ordonnancement de processus légers sur architectures multiprocesseurs
hiérarchiques : BubbleSched, une approche exploitant la structure du parallélisme des applications.
PhD thesis, Université Bordeaux 1, 351 cours de la Libération — 33405 TALENCE cedex, December
2007. 128 pages.
[50] Samuel Thibault, François Broquedis, Brice Goglin, Raymond Namyst, and Pierre-André Wacrenier.
An Efficient OpenMP Runtime System for Hierarchical Architectures. In Barbara M. Chapman,
Weimin Zheng, Guang R. Gao, Mitsuhisa Sato, Eduard Ayguadé, and Dongsheng Wang, editors,
A Practical Programming Model for the Multi-Core Era, 3rd International Workshop on OpenMP,
IWOMP 2007, Beijing, China, June 3-7, 2007, Proceedings, volume 4935 of Lecture Notes in Computer Science, pages 161–172. Springer, 2008.
[51] Ramkumar V. Vadali, Yan Shi, Sameer Kumar, L. V. Kale, Mark E. Tuckerman, and Glenn J.
Martyna. Scalable fine-grained parallelization of plane-wave-based ab initio molecular dynamics for
large supercomputers. Journal of Comptational Chemistry, 25(16):2006–2022, Oct. 2004.
[52] Gengbin Zheng. Achieving High Performance on Extremely Large Parallel Machines: Performance
Prediction and Load Balancing. PhD thesis, Department of Computer Science, University of Illinois
at Urbana-Champaign, 2005.
[53] Gengbin Zheng, Lixia Shi, and Laxmikant V. Kalé. Ftc-charm++: An in-memory checkpoint-based
fault tolerant runtime for charm++ and mpi. In 2004 IEEE International Conference on Cluster
Computing, pages 93–103, San Dieago, CA, September 2004.
08-ANR-SEGI-025
Page 20

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

Documents connexes

Produits

Soutien

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

Documents connexes

Ajouter ce document à la (aux) collections

Ajouter ce document à enregistré

Suggérez-nous comment améliorer StudyLib