Couplage

1
Couplage à hautes performances de codes
parallèles et distribués
Hamid-Reza HAMIDI Thèse préparée dans le
projet APACHE puis le projet MOAIS au sein du
laboratoire ID-IMAG et financée par lIran et la
France (SFERE) 5 Oct 2005 Montbonnot - France
2
Contexte calcul scientifique

• But Etude de phénomènes complexes impliquant
  plusieurs modèles déjà étudiés
• Nécessite lexécution de plusieurs codes
• différents langages de programmation (C, F90,
  HPF, OpenMP, )
• différents paradigmes de communication (RPC/RMI,
  MPI, ...)
• besoin très important de puissance (calcul,
  stockage, visualisation)

Visualisation
Méthode du Continuum
simulation moléculaire complexe ARC SIMBIO
97-99 ARC COUPLAGE 00-01
Dynamique Moléculaire
3
Problématique Couplage de codes

• Construction dapplications distribuées
• certains codes sont parallélisés
• Des objectifs complémentaires
• Calcul parallèle
• Exploitation de larchitecture
• Performances
• Systèmes distribués
• Réutilisation de codes existants
• Hétérogénéité du logiciel et du matériel

?
4
Approche orientée composant

• Un modèle  structuré  de programmation
• concept structurant objets ou composants
• composants sont interconnectés par un intergiciel
• CORBA, PACO, Pardis, FlowVR
• besoin dun modèle/langage de  coordination 
• assemblage des composants

5
Coordination de composants

• Séparation de la partie calculatoire et de la
  partie contrôle
• Définition des composants le calcul
• interface, cycle de vie, déploiement, ...
• Description des interactions entre composants
  le contrôle
• flux de données, dépendance écrivain-lecteur,
  expression, ...
• Problèmes
• Deux langages
• un langage (parallèle) pour la description du
  code des composants
• un langage pour la description de la coordination
  entre composants
• Ordonnancement sur une architecture distribuée
• quel modèle dexécution ?

6
Thèse coordination pour le couplage de codes

• Quel langage de coordination permettant à la fois
  
• exécution parallèle
• passage à léchelle
• adaptation aux ressources
• ordonnancement
• Il existe des langages parallèles pour ces deux
  points
• Linda, Stampede, FlowVR, Athapascan
• Contribution
•  Athapascan  comme langage de coordination
• deux extensions
• HOMA compilateur CORBA support exécutif
• application au couplage de codes dans une grille
  RPC (CORBA)

7
Plan

• Athapascan  flot de données macroscopique 
• Modèle de programmation et dexécution
• Limitations pour la coordination
• Extension dAthapascan comme un langage de
  coordination
• Collection temporelle
• Collection spatiale
• HOMA compilateur de CORBA pour une coordination
  efficace
• Dédié  grille de calcul RPC 
• Implémentation sur Athapascan
• Evaluations expérimentales
• Mesures élémentaires
• Mesures sur une application réelle SIMBIO
• Conclusion et perspectives

8
Athapascan/Kaapi

• Une API de haut niveau Athapascan98
• Permet de construire une représentation de
  lexécution par interprétation de certaines
  instructions
• Expression explicite du parallélisme et contrôle
  implicite des interactions
• une tâche dans le programme une succession
  dinstructions
• création dune tâche mot clé  Fork 
• une donnée dans la mémoire une succession de
  valeurs (versions)
• création dune donnée et laccès initial
  déclaration  Shared 
• Représentation de lexécution graphe de flot de
  données
• Objet important pour le calcul dun
  ordonnancement
• Connaissance des précédences et des
  communications
• Modèle algorithmique de coût prédictif
• Un support exécutif KAAPI Kaapi04
• Ordonnancement en ligne
• Bonnes performances
• Grille hétérogène

9
Athapascan exemple et exécution (1/2)

•  Fork  création de tâche
•  Shared  création de donnée
•  Shared_w  accès en écriture
•  Shared_r  accès en lecture
• Programme indépendant de larchitecture

struct t1 void operator( Shared_wltintgt p )
struct t4 void operator(
Shared_rltintgt p1, Shared_rltintgt p2)
10
Athapascan exemple et exécution (2/2)

• Calcul en ligne des dépendances
• anticipation du futur de lexécution
• meilleur contrôle sur
• mouvement des données
• ordonnancement des tâches
• libération automatique de la mémoire

Interprétation abstraite à lexécution
Ordonnancement
ressource de calcul
11
Sémantique séquentielle

• Quelles sont les versions retournées lors des
  accès en lecture ?
• Sémantique Athapascan séquentielle un accès en
  lecture retourne la dernière version produite
• Adapté au calcul scientifique
• Lisibilité Performance Doreille 99, Maillard
  02, Revire 04

Par rapport à un ordre lexicographique
donnée partagée
version
accès en lecture
accès en écriture
12
Athapascan garantie de performances

• Un modèle algorithmique de coût
• Le temps dexécution parallèle sur P machines
• Tp O(T1 / p T? h( C1 / p C? ))
  O( ? )
• les temps de calcul sans communication (modèle
  PRAM)
• T1 la somme de temps dexécution de toutes les
  tâches
• T? le temps dexécution dun chemin critique
• les temps de communication sur architecture
  homogène
• C1 (latence séquentielle) la somme de tailles
  de toutes les données
• C? (latence parallèle) la somme de tailles de
  données sur un chemin critique
• h le coût denvoi dune unité de données
• ? le coût de lalgorithme dordonnancement

Exécution parallèle
Communication parallèle
13
Distribution spatiale des données et limitation 1

• Athapascan différentes versions dune donnée
  sont distribuées sur plusieurs machines
• ex. X est un vecteur
• Limitation 1 pas de support direct pour les
   données parallèles 
• Comment exprimer la distribution dune version de
  donnée sur plusieurs machines ?

mémoire partagée
donnée partagée X
...
version
...
X
accès en lecture
accès en écriture
machine A
machine B
machine C
mémoire partagée
...
...
X
14
Sémantique séquentielle et limitation 2

• Limitation-2 besoin de synchronisations  flux
  de données 
• un accès en lecture retourne la valeur produite
  par une écriture selon
• un type dentrelacement donné
• des conditions à lexécution
• Exemple flux FIFO  

tâche
tâche
tâche
tâche
tâche
tâche
tâche
mémoire partagée
...
...
X
donnée
version
accès en lecture
Ordre
accès en écriture
Ordre
15
Plan

• Athapascan  flot de données macroscopique 
• Modèle de programmation et dexécution
• Limitations pour la coordination
• Extension dAthapascan comme un langage de
  coordination
• Collection temporelle
• Collection spatiale
• HOMA compilateur de CORBA pour une coordination
  efficace
• Dédié  grille de calcul RPC 
• Implémentation sur Athapascan
• Evaluations expérimentales
• Mesures élémentaires
• Mesures sur une application réelle SIMBIO
• Conclusion et perspectives

16
Comment lever ces limitations ?

• Se baser sur une nouvelle définition des objets
  partagés
• Intérêt
• Conserve le modèle de programmation et le support
  dexécution

Définition Athapascan objet partagé X
succession de versions
Définition proposée objet partagé X ensemble
daccès
mémoire partagée
mémoire partagée
...
...
...
...
X
X
 Shared 
Temps
Temps
 Shared 
donnée dans la mémoire
version
accès en lecture  Shared_r 
accès en écriture  Shared_w 
17
Collection spatiale et collection temporelle

• Collection spatiale  SpaceCollection 
• But  données parallèle  distribution dune
  version sur plusieurs machines
• Définition ensemble daccès fonction
  dindexation
• accès à la i-ème partie dune version distribuée
• Collection temporelle  TimeCollection 
• But description de synchronisations de type
   flux de données 
• Definition ensemble daccès un ordre
  explicite
• un ordre explicite donné par
• un type dentrelacement donné (FIFO,
  Last-Received, ...)
• des conditions à l exécution (ex. tampon borné)

18
Exemples dutilisation

• Collection spatiale  SpaceCollection 
• SpaceCollectionltTgt x // x vecteur de T
• Accès à un élément xi référence vers un
  objet partagé T
• la donnée T nest pas directement accessible
• ForkltUtilisation dun élémentgt( xi )
• Collection temporelle  TimeCollection 
• TimeCollection_wltTgt tc_w // flux de sortie
  déléments T
• TimeCollection_rltTgt tc_r // flux dentrée
  déléments T
• Accès à un élément xi référence vers un
  objet partagé T
• la donnée T nest pas directement accessible
• ForkltEcriture dun élémentgt( tc_w.get_next() )
• ForkltLecture dun élémentgt( tc_r.get_next() )

19
Conclusion

• Résultat
• Un langage de coordination avec une implantation
  efficace
• Extensions à Athapascan pour exprimer des
  synchronisations complexes
• Implémentation efficace sur le support exécutif
  dAthapascan
• Comment utiliser ce langage pour des applications
  effectives ?
• HOMA un compilateur pour des applications
  décrites en CORBA

20
Plan

• Athapascan  flot de données macroscopique 
• Modèle de programmation et dexécution
• Limitations pour la coordination
• Extension dAthapascan comme un langage de
  coordination
• Collection temporelle
• Collection spatiale
• HOMA compilateur de CORBA pour une coordination
  efficace
• Dédié  grille de calcul RPC 
• Implémentation sur Athapascan
• Evaluations expérimentales
• Mesures élémentaires
• Mesures sur une application réelle SIMBIO
• Conclusion et perspectives

21
Exemple SIMBIO (INRIA 97-99)

• Code de simulation numérique de système
  moléculaire complexe impliquant plusieurs modèles
  physiques
• Les codes sont des objets CORBA
• Un code  Pilote  contrôle la simulation
• Deux modèles dinteraction
• Invocation de méthode à distance (RMI)
• Flux de données non traité

22
Problématique

• Lalgorithme de couplage une séquence de RMIs
• Extraction automatique de parallélisme sur les
  RMIs
• Gestion automatique des communications parallèles

server-1
code du pilote
int a, b, c server-1.m1 ( a ) // a en
out server-2.m2 ( b ) // a en out server-1.m3 (
c ) // c en inout server-3.m4 ( a, b ) // a, b
en in
RMI
RMI
server-2
RMI
server-3
données en sortie
données en entrée
23
Approche dHOMA

• Passage du code dun pilote à un ordonnancement
  global distribué de lapplication
• Deux étapes
• 1. Compilation IDL vers Athapascan
• 1 invocation 1 tâche
• 1 paramètre 1 donnée partagée
• 2. Ordonnancement et exécution
• Dynamique, par le runtime Athapascan
• Points critiques
• Recouvrement des latences des RMIs
• Optimisation des transferts de données

DAG associé
code du pilote
int a, b, c server-1.m1 ( a ) // a en
out server-2.m2 ( a ) // a en out server-1.m3 (
c ) // c en inout server-3.m4 ( a, b ) // a, b
en in
t1
t2
t3
Calcul en ligne des dépendance
a
b
c
t4
Ordonnancement
ressource de calcul
24
Point critique I recouvrement des RMIs

• Invocation de RMI gt attente du retour de lappel
• Solution HOMA transforme 1 invocation en 2
  tâches
• 1- une tâche prête qui invoque une méthode
  non-bloquante
• 2- la tâche  continuation  qui met à jour les
  données
• Recouvrement possible grâce à lordonnancement
  non préemptif des tâches Athapascan

Client
Serveur
Serveur
Client
création de tâche
Invocation bloquante
continuation
Invocation non-bloquante
réception
réception
attente
réponse
réponse
résultats
résultats
Invocation-par-Continuation  HOMA
Invocation synchrone  CORBA
25
Point critique II communication parallèle

• Éviter le transfert inutile de données via client
  
• Solution communication lorsque nécessaire
  (lecture ou écriture effective)
•  Cache distribué  pour éviter les
  communications
• 1- cache de données en sortie permettant la
  communication parallèle
• 2- cache de données en entrée évitant la
  duplication des communication

Client
Client
requête
requête
données
référence
1
2
3
4
1
2
3
6
Acq.
référence
données
Acq.
4
référence
Serveur-C
Serveur-P
Serveur-C
Serveur-P
5
données
Protocole standard  CORBA
Communication-par-nécessité  HOMA
26
Fonctionnement de CORBA

• Le compilateur IDL génère le  stub client  et
  le  squelette serveur 
•  stub client  et  squelette serveur  prend
  en charge linvocation à distance

Description dinterface
interface server1 void m3( T in a, T in b
)
Serveur
Client
Objet
Objet
Squelette
compilateur IDL
Stub
POA
Bus logiciel (ORB)
27
Fonctionnement de HOMA

• Le compilateur dHOMA génère un  stub étendu 
   squelette étendu 
• Lexécution dun stub étendu permet
• linterception les invocations de méthodes pour
  créer des tâches Athapascan
• Athapascan contrôle lordonnancement local des
  tâches

Description dinterface
interface server1 void m3( T in a, T in b
)
Serveur
Client
Objet
Objet
compilateur HOMA
Squelette
Stub étendu
interface étendu
Squelette étendu
compilateur IDL
Stub
POA
Bus logiciel (ORB)
28
Résultats théoriques

• HOMA génère un  bon  programme Athapascan
• 1- les tâches sont non bloquantes
   invocation-par-continuation 
• 2- communication directe  communication-par-nec
  éssité 
• Autorise lordonnancement local non préemptif
  parallèle et efficace
• Intérêt HOMA hérite du modèle de coût
  Athapascan
• Le temps dexécution dun code sur P machines
• THOMA Tp O( T1 / p T? h( C1 / p C? ) )
  O( ? )
• Mieux que CORBA qui séquentialise les appels RMI
  distants
• TCORBA O( T1 h C1 ) O( ? )
• Pour un programme très parallèle (T? ltlt T1)
  impliquant un grand volume de données (C? ltlt C1)
  exécuté sur P machines
• THOMA TCORBA / P

Exécution séquentielle
Communication via client
29
Plan

• Athapascan  flot de données macroscopique 
• Modèle de programmation et dexécution
• Limitations pour la coordination
• Extension dAthapascan comme un langage de
  coordination
• Collection temporelle
• Collection spatiale
• HOMA compilateur de CORBA pour une coordination
  efficace
• Dédié  grille de calcul RPC 
• Implémentation sur Athapascan
• Evaluations expérimentales
• Mesures élémentaires
• Mesures sur une application réelle SIMBIO
• Conclusion et perspectives

30
Mesures expérimentales

• Mesures élémentaires sur HOMA
• les surcoûts dinvocation de méthode non
  présenté
• communication parallèle dues aux invocations
  parallèles
• Une application réelle SIMBIO
• exécution parallèle
• Plate-forme expérimentale une grappe de PC
• OmniORB3 CORBA
• iCluster-I de lINRIA
• PC 733 Mhz,
• 256 MB, réseau fast-ethernet 100Mb/s

31
Mesures élémentaires II

• Mesurer la communication parallèle
• Analyse du coût sur N machines
• K la taille de données
• N le nombre de pairs de serveurs
• T1 O( N ) , T? O( 1 )
• C1 O( NK ) , C? O( 1 )
• HOMA THOMA TN O( K )
• CORBA TCORBA O( NK )

code du pilote en CORBA
Exécution du programme Athapascan
for i1 to N do SPi-gtms ( xi ) // x en
sortie SCi-gtmc ( xi ) // x en entrée
HOMA
SP1.ms
SPN.ms
x1
xN
SC1.mc
SCN.mc
32
Résultats expérimentaux II
Nombre de serveurs
33
Bande passante cumulée

• Le bande passante pair-à-pair moyenne
• HOMA 9.5 Mbytes/s, MPI (TCP) 11 Mbytes/s,
  PACO de 9.1 à 11.3MBytes/s

34
Retour à lapplication SIMBIO

• Un code  Pilote  contrôle la simulation

serverMC
Méthode du Continuum
CORBA
RMIs
Dynamique Moléculaire
Pilote
serverDM
35
Pilote de SIMBIO

• Pilote de SIMBIO en CORBA

1. for(int k0 k ltMaxTimeStep k)
2. md-gtcomputeFF(Pin, Fmdout)
3. if (cmstep( k ))
4. md-gtcomputeRhs(Pin, bout)
5. cm-gtcomputeA(Sin,Pin,Vinout)
6. cm-gtcomputePol(bin,Fcmout)
8. md-gtmix(Fcmin,Fgout,Fmdinout)
9. md-gtintegrate(Vinout,Fmdin,Pinout)
10. if (cmstep( k ))
11. cm-gtintegrate(Sinout,Fgin)

36
Résultats expérimentaux - II

• Lapplication SIMBIO

Le temps dexécution sur p machines
gaine 2.98
gaine 10.57
Taille de données
37
Conclusion

• Un même code pour décrire coordination
  exécution
• Vers un modèle unifié Athapascan/Kaapi FlowVR
• Athapascan un langage de coordination
• Description en ligne des dépendances
• Découpage de la déclaration dun accès de laccès
  effectif aux données
• Les extensions
• Collection temporelle donner une consistance
  temporelle
• Collection spatiale décrire des données
  parallèles
• Données irrégulières la distribution de données
  nest pas connue à la compilation mais contrôlée
  à lexécution
• Utilisation dans une  grille RPC  pour les
  applications CORBA
• Appliquer le modèle dexécution dAthapascan
• Exécution non-préemptive par  invocation-par-cont
  inuation 
• Communication parallèle par  communication-par-né
  cessité 
• En se basant sur le développement dun
  compilateur IDL vers Athapascan/Kaapi
• Transparence à lutilisation

38
Perspectives

• Expérimentales
• Expérimentations sur grille hétérogène
• Intégration de bibliothèque de redistribution de
  données distribuées
• Ouverture de la technologie développée
• Ouverture vers dautre interface dintergiciel
• DCOM (Cape-Open/IFP)
• JavaRMI ?
• Intégration avec PACO / GridCCM

39
Merci
40
Collection temporelle intérêt pratique

• Comparaison sur lutilisation dun flux de
  données (FIFO)
• Expérience de type  calcul et communication 
• Un processus calcule et communique ses résultats
• Un processus lit et calcule
• Programme en Athapscan
• Programme sans collection temporelle
• Lordre des communications suit lordre de
  création des tâches
• Programme avec collection temporelle
• Lordre des communications dépend uniquement de
  la disponibilité des valeurs
• Avantage
• Meilleure recouvrement calcul/communication

41
Résultats expérimentaux I
42
Implantation sur intergiciel de communication

TimeCollection_w
TimeCollection_r
process
process
processus
processus
processus
processus
processus
processus
processus
processus
producteur
consommateur
flux de données
mémoire partagée
mémoire partagée
...
...
...
...
X
X
estampille
receive
send
Intergiciel
43
Résultats expérimentaux

• Comparaison par rapport à laccès direct à un
  flux de données (FIFO)
• iCluster-II de lINRIA Itanium bi-processeurs
  900MHz, 3GB

gain entre 10 à 20
44
Retour à lapplication SIMBIO

• Les serveurs sont des objets CORBA
• Modèle communication est RMI

serverDM
Dynamique Moléculaire MPI Threads
O R B
client
Pilote
serverMC
Méthode du Continuum OpenMP
45
Exemples dutilisation

• Collection spatiale  SpaceCollection 
• SpaceCollectionltTgt x // x vecteur de T
• Accès à un élément xi référence vers un
  objet partagé T
• la donnée T nest pas directement accessible
• ForkltUtilisation dun élémentgt( xi )
• Collection temporelle  TimeCollection 
• TimeCollection_wltTgt tc_w // flux de sortie
  déléments T
• TimeCollection_rltTgt tc_r // flux dentrée
  déléments T
• Accès à un élément xi référence vers un
  objet partagé T
• la donnée T nest pas directement accessible
• ForkltEcriture dun élémentgt( tc_w.get_next() )
• ForkltLecture dun élémentgt( tc_r.get_next() )

46
Illustration et extensions

• Ancien type dobjet partagé dAthapascan
   Shared  accès
• sémantique séquentielle une lecture est liée à
  la dernière écriture
• Extension - I Collection spatiale
   SpaceCollection  accès
• en plus de sémantique associé, les accès
  possèdent une fonction dindexation
• ex. SpaceCollection lt Shared gt
• sémantique précise
• interface de programmation
• dans le mémoire de thèse

mémoire partagée
...
...
X
donnée partagée X
version
accès en lecture
accès en écriture
machine A
1
2
3
machine B
machine C
 SpaceCollection
47
Extension - II collection temporelle

• Collection temporelle  TimeCollection 
  accès
• sémantique de type flux de données
• un ordre implicite donné par
• un type dentrelacement donné (FIFO,
  Last-Received, ...)
• les conditions à l exécution (ex. tampon borné)
•  TimeCollection_r  accès en lecture
•  TimeCollection_w  accès en écriture
• sémantique précise
• interface de programmation
• dans le mémoire de thèse

donnée partagée
mémoire partagée
...
...
version
X
accès en lecture
accès en écriture
Temps
Temps
entrelacement
 TimeCollection_w 
 TimeCollection_r 
48
Problématique - II

• Extraction du parallélisme sur les
  invocations
• Dépendances sur paramètres effectifs
• Dépendances sur états partagés dans une server

3-
ex. de code client
server_1 -gt m1( a ) server_2 -gt m2( b
) server_1 -gt m4( f ) server_3 -gt m3( a, b
) ...

• Solutions existants
•  Request Sequencing  de NetSolve/Ninf
•  ?  de DIET
• explicite et à la charge de utilisateur

server-3
m3
server-2
m2
ex. CORBA
server-1
m1
m4
attent
client
attent
attent
attent
temps
server-3
m3
server-2
m2
Notre approauch
server-1
m1
m4
client
attent
attent
temps
49
Collection spatiale dans SIMBIO

• Tous les objets serveurs et données sont
  distribués sur plusieurs machines

SpaceCollection
SpaceCollection
ATHAPASCAN
ATHAPASCAN
A
A
DM-gtcomputeFF( A, F )
for i1 to N do DMi-gt computeFF(Ai,FI)
MAP (f,C) -gt f(ci)
50
Modèle I problématique - III
Exploitation des données parallèles redistr
ibution de données entre les codes
Server parallèl
Pserver
4-
foo( A )
A
foo( A )
A
Client parallèle
le code client
A
foo( A )
A
... Pserver-gtfoo( A ) ...
foo( A )
A

• Solutions existants
• objet parallèle de PARDIS, PaCO, PaCO (SPMD et
  implicite)
•  Data Parallel CORBA  de OMG (MPMD et
  explicite)
• le client reste toujours le glot detronglement
  de communication

Notre approauch exploiter les solutions
existants dans la communication directe

• Prédiction de l'exécution
• redistribution des données
• ordonnancement de tâches

5-
Notre approauch construction on-line
de graphe de flot de données
51
Interprétation abstraite et larchitecture

• HOMA détecte le parallélisme et les dépendances à
  lexécution
• Le compilateur dHOMA génère le  stub HOMA  de
  linterface donné
•  stub HOMA  intercepte les invocations de
  méthodes pour créer les tâches
• La gestion des dépendances par Athapascan

Client / Pilot
Serveur
Serveur
proxy HOMA
recompilé
non-changé
modèle SPMD
Code
Code
Objet
Objet
Objet
stub Homa
stub Homa
Skeleton
Skeleton étendu
gestion de flot de données ( Athapascan )
Skeleton étendu
Skeleton
POA
POA
POA
Stub
Stub
Stub
Bus logiciel (ORB)