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 l’Iran et la France (SFERE) 5 Oct 2005 Montbonnot - France

Contexte : calcul scientifique But : Etude de phénomènes complexes impliquant plusieurs modèles déjà étudiés Nécessite l’exé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

Problématique : Couplage de codes Construction d’applications distribuées certains codes sont parallélisés Des objectifs complémentaires Calcul parallèle Exploitation de l’architecture Performances Systèmes distribués Réutilisation de codes existants Hétérogénéité du logiciel et du matériel ?

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 d’un modèle/langage de « coordination » assemblage des composants Composant séquentiel process parallèle processus intergiciel grappe Réseau haut débit Réseau Supercomputer Visualisation Architecture logicielle Architecture matérielle

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 d’exécution ?

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)

Plan Athapascan : « flot de données macroscopique » Modèle de programmation et d’exécution Limitations pour la coordination Extension d’Athapascan 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

Athapascan/Kaapi Une API de haut niveau [Athapascan98] Permet de construire une représentation de l’exé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 d’instructions création d’une tâche : mot clé « Fork » une donnée dans la mémoire = une succession de valeurs (versions) création d’une donnée et l’accès initial : déclaration « Shared » Représentation de l’exécution = graphe de flot de données Objet important pour le calcul d’un 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

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 l’architecture programme ATHAPASCAN … Shared<int> a, b, c; Fork<t1>( a ); // “a” Shared_w Fork<t2>( b ); // “b” Shared_w Fork<t3>( c ); // “c” Shared_w Fork<t4>( a, b ); // “a, b” Shared_r ... … struct t1 { void operator( Shared_w<int> p ) { … } }; struct t4 { void operator( Shared_r<int> p1, Shared_r<int> p2)

Athapascan : exemple et exécution (2/2) b t4 t1 a Représentation de l’exécution t3 c tâche version accès Calcul en ligne des dépendances anticipation du futur de l’exécution meilleur contrôle sur : mouvement des données ordonnancement des tâches libération automatique de la mémoire programme ATHAPASCAN … Shared<int> a, b, c; Fork<t1>( a ); // “a” Shared_w Fork<t2>( b ); // “b” Shared_w Fork<t3>( c ); // “c” Shared_w Fork<t4>( a, b ); // “a, b” Shared_r ... Interprétation abstraite à l’exécution Ordonnancement ressource de calcul

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 mémoire partagée tâche X ... Ordre donnée partagée version accès en lecture accès en écriture

Athapascan : garantie de performances Un modèle algorithmique de coût Le temps d’exé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 d’exécution de toutes les tâches T : le temps d’exécution d’un 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 d’envoi d’une unité de données  : le coût de l’algorithme d’ordonnancement Exécution parallèle Communication parallèle

Distribution spatiale des données et limitation 1 Athapascan : différentes versions d’une 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 d’une version de donnée sur plusieurs machines ? donnée partagée X mémoire partagée version X ... ... accès en lecture accès en écriture machine A machine B machine C mémoire partagée ... ... X

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 d’entrelacement donné des conditions à l’exécution Exemple : « flux FIFO »   tâche tâche tâche . . . flux de données tâche tâche tâche tâche mémoire partagée ... ... X donnée version accès en lecture accès en écriture Ordre Ordre

Plan Athapascan : « flot de données macroscopique » Modèle de programmation et d’exécution Limitations pour la coordination Extension d’Athapascan 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

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 d’exécution Définition Athapascan : objet partagé X = succession de versions Définition proposée: objet partagé X = ensemble d’accès mémoire partagée mémoire partagée ... ... ... ... X X « Shared » Temps Temps donnée dans la mémoire « Shared » version accès en lecture « Shared_r » accès en écriture « Shared_w »

Collection spatiale et collection temporelle Collection spatiale « SpaceCollection » But: « données parallèle » distribution d’une version sur plusieurs machines Définition : ensemble d’accès + fonction d’indexation accès à la i-ème partie d’une version distribuée Collection temporelle « TimeCollection » But: description de synchronisations de type « flux de données » Definition : ensemble d’accès + un ordre explicite un ordre explicite donné par : un type d’entrelacement donné (FIFO, Last-Received, ...) des conditions à l ’exécution (ex. tampon borné)

Exemples d’utilisation Collection spatiale « SpaceCollection » SpaceCollection<T> x; // x ~ vecteur de T Accès à un élément : x[i] = référence vers un objet partagé T la donnée T n’est pas directement accessible Fork<Utilisation d’un élément>( x[i] ) Collection temporelle « TimeCollection » TimeCollection_w<T> tc_w; // flux de sortie d’éléments T TimeCollection_r<T> tc_r; // flux d’entrée d’éléments T Fork<Ecriture d’un élément>( tc_w.get_next() ) Fork<Lecture d’un élément>( tc_r.get_next() )

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 d’Athapascan Comment utiliser ce langage pour des applications effectives ? HOMA : un compilateur pour des applications décrites en CORBA

Plan Athapascan : « flot de données macroscopique » Modèle de programmation et d’exécution Limitations pour la coordination Extension d’Athapascan 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

Exemple : SIMBIO (INRIA 97-99) HOMA 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 d’interaction Invocation de méthode à distance (RMI) Flux de données [non traité] Pilote Visualisation Bordeaux Dynamique Moléculaire Méthode du Continuum Nancy Grenoble CORBA . . . flux de données RMIs

Problématique L’algorithme de couplage = une séquence de RMIs HOMA Problématique L’algorithme de couplage = une séquence de RMIs Extraction automatique de parallélisme sur les RMIs Gestion automatique des communications parallèles server-1 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 code du pilote RMI RMI server-2 RMI server-3 données en sortie données en entrée

HOMA Approche d’HOMA Passage du code d’un pilote à un ordonnancement global distribué de l’application 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 t3 t2 Calcul en ligne des dépendance a c b t4 Ordonnancement ressource de calcul

Point critique I : recouvrement des RMIs HOMA Point critique I : recouvrement des RMIs Invocation de RMI => attente du retour de l’appel 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 à l’ordonnancement non préemptif des tâches Athapascan Client Serveur Client Serveur création de tâche Invocation bloquante continuation réception Invocation non-bloquante réception attente réponse réponse résultats résultats Invocation synchrone « CORBA » Invocation-par-Continuation « HOMA »

Point critique II : communication parallèle HOMA 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 4 Acq. référence Serveur-P Serveur-C Serveur-P 5 Serveur-C données Protocole standard « CORBA » Communication-par-nécessité « HOMA »

Fonctionnement de CORBA HOMA Fonctionnement de CORBA Le compilateur IDL génère le « stub client » et le « squelette serveur » « stub client » et « squelette serveur » prend en charge l’invocation à distance interface server1{ void m3( T in a, T’ in b ); } Description d’interface Client Serveur Objet Objet Squelette compilateur IDL Stub POA Bus logiciel (ORB)

Fonctionnement de HOMA Le compilateur d’HOMA génère un « stub étendu » + « squelette étendu » L’exécution d’un stub étendu permet : l’interception les invocations de méthodes pour créer des tâches Athapascan Athapascan contrôle l’ordonnancement local des tâches interface server1{ void m3( T in a, T’ in b ); } Description d’interface Client Serveur Objet Objet compilateur HOMA Squelette Stub étendu interface étendu Squelette étendu compilateur IDL Stub POA Bus logiciel (ORB)

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 l’ordonnancement local non préemptif parallèle et efficace Intérêt : HOMA hérite du modèle de coût Athapascan Le temps d’exécution d’un 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 << T1) impliquant un grand volume de données (C << C1) exécuté sur P machines THOMA = TCORBA / P Exécution séquentielle Communication via client

Plan Evaluations expérimentales Athapascan : « flot de données macroscopique » Modèle de programmation et d’exécution Limitations pour la coordination Extension d’Athapascan 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

Mesures expérimentales HOMA Mesures expérimentales Mesures élémentaires sur HOMA les surcoûts d’invocation 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 l’INRIA PC 733 Mhz, 256 MB, réseau fast-ethernet 100Mb/s

Mesures élémentaires II HOMA 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( N*K ) , C = O( 1 ) HOMA : THOMA = TN = O( K ) CORBA : TCORBA = O( N*K ) for i=1 to N do SP[i]->ms ( x[i] ); // x en sortie SC[i]->mc ( x[i] ); // x en entrée code du pilote en CORBA Exécution du programme Athapascan HOMA SP[1].ms SP[N].ms x[1] x[N] SC[1].mc SC[N].mc

Résultats expérimentaux II HOMA Résultats expérimentaux II 5 1 2 3 4 8 6 N u m b e r o f s v Time (sec) C O R B A 9 , M H a Nombre de serveurs

Bande passante cumulée HOMA 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 5 1 2 3 4 8 6 N o m b r e d p a i s v u Mbyte/sec Bloc , M B

Retour à l’application SIMBIO HOMA Retour à l’application SIMBIO Un code « Pilote » contrôle la simulation serverMC Méthode du Continuum CORBA RMIs Dynamique Moléculaire Pilote serverDM

Pilote de SIMBIO Pilote de SIMBIO en CORBA Dépendances complexes ! HOMA Pilote de SIMBIO Pilote de SIMBIO en CORBA for(int k=0; k <MaxTimeStep; k++){ md->computeFF(Pin, Fmdout); if (cmstep( k )){ md->computeRhs(Pin, bout); cm->computeA(Sin,Pin,Vinout); cm->computePol(bin,Fcmout); } md->mix(Fcmin,Fgout,Fmdinout); md->integrate(Vinout,Fmdin,Pinout); if (cmstep( k )) cm->integrate(Sinout,Fgin); Dépendances complexes !

Résultats expérimentaux - II HOMA Résultats expérimentaux - II L’application SIMBIO Le temps d’exécution sur p machines gaine 2.98 gaine 10.57 Taille de données

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 d’un accès de l’accè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 n’est pas connue à la compilation mais contrôlée à l’exécution Utilisation dans une « grille RPC » pour les applications CORBA Appliquer le modèle d’exécution d’Athapascan Exécution non-préemptive par « invocation-par-continuation » Communication parallèle par « communication-par-nécessité » En se basant sur le développement d’un compilateur IDL vers Athapascan/Kaapi Transparence à l’utilisation

Perspectives Expérimentales Ouverture de la technologie développée 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 d’autre interface d’intergiciel DCOM (Cape-Open/IFP) JavaRMI ? Intégration avec PACO++ / GridCCM

Merci

Collection temporelle : intérêt pratique Comparaison sur l’utilisation d’un 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 L’ordre des communications suit l’ordre de création des tâches Programme avec collection temporelle L’ordre des communications dépend uniquement de la disponibilité des valeurs Avantage Meilleure recouvrement calcul/communication

Résultats expérimentaux I HOMA Résultats expérimentaux I

Implantation sur intergiciel de communication TimeCollection_w TimeCollection_r process processus process processus processus processus processus processus . . . processus processus producteur consommateur flux de données mémoire partagée ... ... mémoire partagée ... ... X X estampille send receive Intergiciel

Résultats expérimentaux Comparaison par rapport à l’accès direct à un flux de données (FIFO) iCluster-II de l’INRIA Itanium bi-processeurs 900MHz, 3GB gain entre 10% à 20%

Retour à l’application SIMBIO HOMA Retour à l’application 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

Exemples d’utilisation Collection spatiale « SpaceCollection » SpaceCollection<T> x; // x ~ vecteur de T Accès à un élément : x[i] = référence vers un objet partagé T la donnée T n’est pas directement accessible Fork<Utilisation d’un élément>( x[i] ) Collection temporelle « TimeCollection » TimeCollection_w<T> tc_w; // flux de sortie d’éléments T TimeCollection_r<T> tc_r; // flux d’entrée d’éléments T Fork<Ecriture d’un élément>( tc_w.get_next() ) Fork<Lecture d’un élément>( tc_r.get_next() )

Illustration et extensions Ancien type d’objet partagé d’Athapascan « 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 d’indexation ex. SpaceCollection < Shared > *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»

Extension - II: collection temporelle Collection temporelle « TimeCollection » = { accès } sémantique de type flux de données un ordre implicite donné par : un type d’entrelacement 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 »

explicite et à la charge de utilisateur 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- … server_1 -> m1( a ); server_2 -> m2( b ); server_1 -> m4( f ); server_3 -> m3( a, b ); ... ex. de code client 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 client attent attent attent attent temps server-3 m3 server-2 Notre approauch m2 server-1 m1 m4 client attent attent temps

Collection spatiale dans SIMBIO HOMA Collection spatiale dans SIMBIO Tous les objets serveurs et données sont distribués sur plusieurs machines SpaceCollection SpaceCollection ATHAPASCAN ATHAPASCAN A A DM->computeFF( A, F ) for i=1 to N do DM[i]-> computeFF(A[i],F[I]) MAP : (f,C) -> {f(c[i])}

Modèle I: problématique - III HOMA Modèle I: problématique - III 4- Exploitation des “données parallèles” redistribution de données entre les codes Server parallèl Pserver A foo( A ) A foo( A ) Client parallèle le code client A A foo( A ) ... Pserver->foo( 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 d’etronglement de communication Notre approauch :exploiter les solutions existants dans la communication directe 5- Prédiction de l'exécution redistribution des données ordonnancement de tâches Notre approauch : construction on-line de graphe de flot de données

Interprétation abstraite et l’architecture HOMA Interprétation abstraite et l’architecture HOMA détecte le parallélisme et les dépendances à l’exécution Le compilateur d’HOMA génère le « stub HOMA » de l’interface 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 recompilé proxy HOMA modèle SPMD non-changé Code Code Objet stub Homa stub Homa Objet Objet Skeleton Skeleton étendu gestion de flot de données ( Athapascan ) Skeleton étendu Skeleton POA Stub Stub POA Stub POA Bus logiciel (ORB)