Franck Cappello Groupe Clusters et Grilles Laboratoire de Recherche en Informatique,

1. Modèles d’exécution parallèles pour les architectures hautes performances et les grands systèmes distribués Franck Cappello Groupe Clusters et Grilles Laboratoire de Recherche en Informatique, Université Paris Sud, Orsay, fci@lri.fr http://www.lri.fr/~fci

2. Sommaire • Introduction aux Modèles d’exécution • QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP • OVM: un modèle d’exécution pour les applications régulières et irrégulières • XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle • Conclusion et Perspectives

3. Applications, architectures, langages et modèles d’exécution De plus en plus d’utilisateurs (industries, laboratoires de recherche) ont recours au calcul haute performance. Les architectures évoluent vers des agrégats avec des niveaux de couplage variables Météorologie Physique des hautes énergies Bio informatique Traitement d’images Synthèses d’images Simulation de Microprocesseurs Etc. Clusters de SMP Langages de programmation et modèles d’exécution sont les pierres angulaires pour atteindre les hautes performances sur les machines parallèles PC Clusters Applications régulières: Sans équilibrage de charge Applications irrégulières: Avec équilibrage de charge Limitée par les performances de calcul (compute bound) Limitée par les performances d’entrées-sorties (I/O bound) GRID, Calcul Global, P2P

4. Place fondamentale du modèle d’exécution Applications Modèle de programmation Ex : dataparallélisme, modèle concurrent, maître-esclave Expression Langages Langages standards : Fortran, C, C++, Java, Matlab, Scilab Modèle d’exécution Passage de Messages : MPI, OVM (RPC), Mémoire Virtuellement partagée :Scach, TreadMarks, Interface de Program. d’Appli. Environ. de résolution de problèmes : Netsolve, Ninf, Environnement d’exécution Système de Calcul Global : Globus, Legion, XtremWeb Passage de messages pour GRID: MPICH-G, Machine virtuelle Mem. virtuellement partagée pour GRID: OmniOpenMP GRID, Calcul Global, P2P Système d’exploitation Architectures Matériel d’exécution Clusters de SMP Clusters

5. Rôle fondamental pour la portabilité des codes et la virtualisation des architectures Entropia, United Dev Architectures SETI@home Grds sys. dist Grilles locales Cluster X86, Alpha, Itanium 500 SIMD Compaq SC Constellation (cluster SMP) Sun HPC cluster NEC SX4 / Earth TOP 500 SGI O3000 / 2000 400 HP Hyperplex Sun HPC 10000 MPP 300 IBM SP3 Hitachi SR8000 CRAY T3E 200 Fujitsu VPP 5000 100 SMP Mono HP superdome Processeur NEC SX 5 0 93 94 96 97 98 99 00 95

6. Trois angles de recherche • Objectif : • Isoler et comprendre les mécanismes fondamentaux de la programmation haute performances des architectures parallèles complexes et • des grands systèmes distribués • applications régulières avec environnements standards (MPI et OpenMP) • un environnement d’exécution pour les applications régulières et • irrégulières • un environnement d’exécution pour les clusters à couplage très lâche Programmation efficace des architectures complexes avec MPI et OpenMP Out-of-order execution parallel Virtual Machine (une machine parallèle virtuelle à ordonnancement macro dataflow) Une plate-forme expérimentale du Calcul global et Pair à Pair

7. Le projet Little TiPI du LRI • Doctorant : Olivier Richard (co-encadré) • Etude des clusters de PC multiprocesseurs • Début du projet 1996 • Cluster de bi Pentium pro en 1997 • Cluster de bi Pentium II 300 en 1998 • Cluster de quadri P II Xeon en 1999 • Cluster de bi Pentium III 500 en 2000 • Sujets de recherche • caractérisation de la charge des serveurs • et des stations dans un site informatique • adaptation de MPI pour cluster de multipro • début d’OVM • Collaborations : • RWCP (Score), Université de Bonn, Labo de math PXI, IBM France Little TiPI en 1998 1997 4x4 Clump en 1999

8. Sommaire • Introduction aux Modèles d’exécution • QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP • OVM: un modèle d’exécution pour les applications régulières et irrégulières • XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle • Perspectives

9. Noeud Noeud Passage de Messages Mémoire Mémoire bus E/S Interface Réseau Réseau Processeurs Processeurs Commutateur NUMA Mémoire partagée Le projet QUID: Programmer efficacement les architectures parallèles complexes Doctorant : Géraud Krawezik IDRIS, CINES, CEA, ORNL, LLNL, SDSC, Etc. IBM SP3, Compaq SC SGI Origin 2K, IBM Power4 Compaq ev7, SGI Origin 3K Earth Simulator Sujets de recherche : Quel modèle utiliser pour les applications SPMD (appli. MPI existantes) ? Passage de messages ? ou Hybride (PM + Mémoire Partagée) Collaborations :ORNL (accès aux machines), IBM ACTC, Université de Tsukuba, EADS (CIFRE)

10. Etat de l’art • Etude simulation de courant océanique (SDSC) peu de noeuds • Produit matrice-vecteur (Karlsruhe) peu de noeuds • Prédiction de vague –CGWAVE- (US Major Shared Resource Center) résolution d’un grand système creux par gradient conjugué (solveur de Krylov sur les nœuds) • ACTC (IBM) quelques résultats sur peu de noeuds • Dynamique des fluides sur grille non structurée (ASCI RED) • … 1) Assez peu d’études publiées2) Peu de comparaisons entre hybride et Pass. de Messages3) Pas de résultat permettant de comprendre pourquoi un modèle serait meilleur que l’autre dans le cas général

11. Modèle à passage de messages « tout MPI » : • communication en espace utilisateur • communication intra SMP à travers la mémoire partagée Noeud Noeud Mémoire Mémoire Communication intra-noeud Communication inter-noeud Processeurs Processeurs Les programmes MPI fonctionnent sans modification

12. Modèle hybride « grain fin » Passage de messages Passage de messages (SPMD) (Original MPI prog.) + mémoire partagée (OpenMP) Section séquentielle seq part seq Section à 1 thread part Initialisation init MPI init SMP part init // part Calcul. calcul non parall. Section à >=1 (OpenMP) comm. Calcul. Section à plusieurs processus parall.. sync sync Terminaison end // part end SMP part Section à 1 thread seq Section séquentielle part

13. 1 2 4 8 16 32 MPI contre MPI+OpenMP NAS 2.3 Classe A, 2 nœuds SP différents (rapport des temps d’exécution) Quadriproceseur (NH1 222-MHz) Quadriprocesseur (WH2 375-MHz) 1 2 4 8 1.5 1,4 1,2 1 1 MPI / MPI+OMP MPI / MPI+OMP 0,8 0.5 0,6 0,4 0 0,2 cg ft lu mg bt sp cg ft lu mg bt sp Rapport < 1 signifie que MPI est meilleur MPI est le meilleur modèle dans la plupart des cas Résultat contre-intuitif ! Pourquoi ?  décomposition du temps d’exécution

14. Coût des sections non parallélisées avec OpenMP Pourcentage du temps d’exécution passé dans les régions parallèles OpenMP Nœuds WH2 (avec 1 processeur/noeud) temps exé parall / temps exé global 1 2 4 8 16 32 1 0,8 0,6 0,4 0,2 0 cg-A cg-B ft - A ft - B lu - A lu - B mg-A mg-B Accélération maximale théorique MPI+OpenMP 1.22 1.65 2.20 2.50 1.56 1.76 1.75 1.71 Les sections non parallélisées sont le facteur limitant principal pour l’approche hybride MPI+OpenMP à grain fin (LU, MG, BT,SP)

15. 1 2 4 8 16 32 Accélération comparée dans les régions purement parallèles Noeuds WH2 4 voies - Class A Nombre de noeuds Efficacité parallèle accélération /nb procs speedup superlinéaire Meilleure utilisation des caches 2,5 2 speedup sub linéaire 1,5 1 0,5 0 Pénalité mémoire cg cg ft ft lu lu mg mg mpi mpi omp mpi mpi omp mpi mpi omp mpi mpi omp • L’efficacité parallèle dans les sections purement parallèles est meilleure avec MPI (résultats similaires avec la classe B) • Il y a deux raisons principales • Organisation des accès mémoire. OpenMP ne permet pas d’exprimer les distributions multi-dimensionnelles des itérations d’un nid de boucles • Surcoût de la gestion et de la synchronisation des threads

16. Coût du partage du support de communication Noeuds WH2 4 voies - Class A calcul mpi Comm mpi calcul mpi+openmp Comm mpi+openmp 30 150 20 100 temps (sec) temps (sec) CG_A Comm. CG_A Calcul 10 50 0 0 1 2 4 8 16 32 • MPI a un temps de calcul plus faible. • MPI+OpenMP a un temps de communication plus faible • N processus contre 4N processus pour N nœuds • messages longs (débit de communication) • Tendance similaire pour MG et FT. • Le temps de communication peut être le facteur limitant leperformances globales pour le modèle MPI (CG, MG, FT)

17. Nouveaux résultats : l’approche « gros grain » Programmer avec OpenMP en suivant le paradigme SPMD Gros grain Grain fin … ! Initialisation MPI !$OMP PARALLEL … do i=1,n … end do MPI_SEND(…) … !$OMP END PARALLEL end … ! Initialisation MPI !$OMP PARALLEL !$OMP DO do i=1,n … end do !$OMP END DO … MPI_SEND(…) … end • Distribution du travail par le programmeur • (adaptation des limites de boucle)  • Parallélisation explicite • Coordination des threads très complexe • (faux partage, synchro) • Un très grand nombre de régions • parallèles • Surcoût très élevé de la gestion • des threads (fork-join, sync)

18. Revenir à un problème plus simple : CG (NAS 2.3) sur 1 nœud SMP Objectif : fournir une version OpenMP de CG produisant les mêmes performances que la version MPI sur une machine SMP • Buts : • Inclure le plus de code possible dans une seule région parallèle • Conserver les nids de boucles de laversion MPI (Seq, MPI) • Utiliser la meilleure technique de réduction possible Schéma de calcul de CG: init part // Calc. Réduction Sync. • Résultats : • Une seule région parallèle • Nids de boucles identiques à MPI • Choix de la technique de réduction parmi 5 possibles (et intuitivementintéressantes) fin part //

19. Barrier atomic DO reduction Barrier tree Lock tree Réduction de 32 valeurs SGI O3.8K 1000 100 Temps ms 10 1 1 2 4 8 16 32 Choix de la technique de réduction Techniques : Barrière Atomic Do Reduction Barrière (en arbre binaire) Verrous (en arbre binaire) Réduction de 32 valeurs SP3 NH2 10000 1000 Temps ms 100 10 1 Nb proc. 1 2 4 8 16

20. ref MPI OMP gros grain OMP grain fin MPI OMP gros grain MPI contre OpenMP sur CG NAS 2.3 Temps passé dans la partie calcul de CG mpi relativement à la version MPI 2,5 OpenMP grain fin (statique) 2 OpenMP gros grain 1,5 1 OpenMP gros grain + attachement 0,5 0 1 2 4 8 16 nb processeurs perf NAS CG A - IBM NH2 (1 noeud) Temps de communication et synchronisation 2500 2000 0,4 0,35 1500 0,3 Mflops 0,25 1000 Temps (s) 0,2 0,15 500 0,1 0,05 0 0 1 2 4 8 16 1 2 4 8 16 nb processeurs nb processeurs

21. Résumé • L’approche MPI unifiée est la plus performante dans le cas général comparativement à l’approche hybride grain fin • Il existe des raisons fondamentales à ce résultat • L’approche gros grain (SPMD, ou à parallélisme explicite) permet d’augmenter significativement les performances d’OpenMP pour les nœuds SMP • La programmation « données non partagées » implique l’utilisation d’opérations globales (et peut être d’échanges point à point) • Les meilleures performances intranoeud et internoeud permettent-elles à l’approche hybride gros grain de dépasser le passage de messages dans le cas général ?

22. Perspectives • Evaluer différentes approches pour les opérations globales : • Bibliothèque d’opérations globales pour threads (HPC++) • Une bibliothèque d’opérations globales pour l’approche OpenMP gros grain sur les machines à mémoire partagée • Approche hybride gros grain pour grappes de multiprocesseurs • 1) avec réseau à passage de messages • 2) avec réseau NUMA – SGI O3000, IBM SP4 • Placement/migration automatique/contrôlé de pages et/ou utilisation des directives de placement proposées pour OpenMP • Cluster de NUMA et Cluster de NUMA cluster de SMP Programmation efficace des architectures parallèles complexes

23. Sommaire • Introduction aux Modèles d’exécution • QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP • OVM: un modèle d’exécution pour les applications régulières et irrégulières • XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle • Conclusion et Perspectives

24. Calc. Calc. Pénalité de cache ou Déséquilibrage de charge Attente comm. comm. sync sync Nécessité d’un environnement unique pour les applications régulières et irrégulières Applications : Régulières, Irrégulières (équilibrage de charge), Certaines Applications irrégulières s’expriment « naturellement » dans le mode Maître-esclave ou fonctionnel récursif Modèle SPMD synchrone et applications réelles sur les architectures // complexes Point de départ Maître Esclaves • 1) Importante dégradation de performance en cas de déséquilibrage de charge • Emuler le mode maître-esclave ou fonctionnel Modèle SPMD synchrone

25. Une sélection d’environnements pour équilibrage de charge Equilibrage de charge dans les environnements multi-flots : Athapascan (graphe dataflow + évaluation distribuée), lab ID, ENSIMAG PM2 (migration de threads), LIFL, ENS Lyon Cilk (vol de travail dans une pile de récursions), MIT Equilibrage de charge à partir de langages objets (95, 96) : Dome (c++ et PVM), SPMD, check point et migration Charm, Charm++, Urbana Chanpaign Equilibrage de charge à partir de PVM/MPI (93-94-95 ; 01) : MPVM (migration de processus unix) Oregon Graduate Institute of S & T. UPVM (migration de threads)Oregon Graduate Institute of S & T. Dynamic PVM (condor checkpoint), University of Amsterdam MPI TM (migration de tâches – core dump) Mississippi State University AMPI (migration de threads par dessus Charm++) Urbana Champaign Dynamite PVM (migration de tâches)

26. Nécessité d’un environnement unique pour une grande variété d’architecture Clusters, SMP, NUMA, Cluster de SMP,Cluster NUMA de SMP, … Cluster de SMP pseudo-vectorielles Cluster de Machines vectorielles Clusters NUMA de SMPs SMP GRID, Calcul Global, P2P Clusters de SMP Cluster de PC Proposer aux programmeurs des environnements portables permettant de pérenniser sinon leurs applications au moins leurs outils/environnements de programmation

27. Une sélection d’environnements pour une grande variété d’architectures Bibliothèques de communication : MPI (MPICH-LAM), PVM Environnement pour la mémoire partagée : OpenMP (OmniOpenMP du RWCP-Université de Tsukuba) Environnements programmation objets : Jade - Université de Stanford Amber - Université de Washinton Environnements programmation objets + macrodataflow : SMARTS pour machines à hiérarchie mémoire profonde - LANL Mentat (langage objet + environnement d’exéction) - Université de Virginie Concert - Université de l’Illinois Bibliothèques de communications pour les Grilles : MPICH-G MPI par dessus Nexus (Globus) - Argonne MPICH-G2 MPI par dessus Globus – Argonne PACX-MPI – Stuttgart (Allemagne) Meta-MPICH -Lehrstuhl für Betriebssysteme  (Allemagne)  Madeleine (PM2) – ENS Lyon 

28. Projet OVM : Un environnement d’exécution bas niveau pour une large variété d’architectures et d’applications Doctorants : George Bosilca, Abderhamane Djilali Sujet de recherche : Une machine virtuelle à ordonnancement macro-dataflow  Continuum entre le modèle SPMD synchrone et le modèle client-serveur Courtier (Broker) Serveurs Client Dataflow Programme Client Mém. API OVM Bib. Fonct. RPCs Ressource Programmeur Ordonnanceur Mém. OVM Bib. Fonct. Collaborations :RWCP, Université de Tsukuba,

29. Différents mode de RPCs Programme client Serveurs Broker RPC Equilibre De charge RPC Fonction RPC RPC RPC Donnée volatile données Programme client Serveurs Broker Broker Gestion données RPC Fonction RPC RPC id id id RPC id RPC Donnée persistante id RPC 1) RPC classique 2) RPC découplé

30. Le moteur macro-dataflow d’OVM Broker Serveurs Tâche Construction du graphe Terminaison Client Tâche Evaluation des dépendances RPCs Lancement Requêtes prêtes Contrôle De flot Tâche Requêtes terminées Destruction du graphe Tâche

31. OVM sur des applications SPMD Objectif : un flot d’exécution serveurs identique au flot MPI Problèmes : masquer le coût de la gestion du macro-ordonnancement Placement cyclique des données persistantes Données persistantes Serveurs données données données données Fonctions de bibliothèques Funct 1 Funct 1 Funct 1 Funct 1 Funct 2 Funct 2 Funct 2 Funct 2 Funct 3 Funct 3 Funct 3 Funct 3 Données du macro ordonnancement données • données persistantes • ordonnancement statique • Opérations globales Client + broker Programme du macro ordonnanceur

32. OVM sur des applications irrégulières Objectif : pas de migrations, nombre de tâches concurrentes Ordonnancement premier arrivé – premier servi Serveurs Fonct * Fonctions de bibliothèques Fonct X Fonct Z Fonct Y données données Données volatiles données données Données du macro ordonnancement données • données volatiles • Ordonnancement dynamique • Pas d’opérations globales Client + broker Programme du macro ordonnanceur

33. Optimisations OVM pour les hautes performances • RPC classique multi-protocoles : • transport des paramètres dans le RPC si taille < 4 Ko • collection asynchrone des paramètres sur le client si données >= 4 Ko • modes bloquant ou non pour le client • Opérations globales non bloquantes : • un serveur passe à la suite du calcul après avoir contribué à l’opération globale • Opérations globales asynchrones : • les opérations globales ne terminent pas forcément dans l’ordre de lancement (permet d’exécuter simultanément des opérations globales indépendantes) • Pré-lancement de tâches en cas de dépendances sur le même serveur (données persistantes) – dataflow hiérarchique • Pré-lancement de tâches en mode RPC (données volatiles), sans vérification de dépendance de ressource pour permettre un recouvrement entre la collection des paramètres du service suivant et l’exécution du service courant. • Cache de données volatiles sur les serveurs • Utilisation simultanée des RPC classiques et découplés,

34. EP MPI EP OVM FT MPI FT OVM CG MPI CG OVM Evaluation de performance sur des applications régulières OVM et MPI pour 3 noyaux du benchmark NAS NPB 2.3 : CG, FT, EP CG : communication de type réduction (petits messages) très fréquentes FT : communication de type all-to-all (grands messages) fréquentes EP : pratiquement pas de communication Cluster de PentiumPro 200 + Myrinet, environnement Score (RWCP) Opérations globales MPI optimisées Performance de CG, FT et EP classe A sur un cluster de PC 1000 100 Temps (s) 10 1 nb procs 2 4 8 16 32

35. Evaluation de performance sur des applications irrégulières OVM pour une version parallèle d’AIRES Code de simulation de particules à très haute énergie Sur-découpage de la pile Blocs iso-énergies Perf de AIRES sur un cluster de PC 100 56,1 26,9 15,4 Accélération 7,66 10 36,8 3,96 20,8 Avec l’initialisation 13,5 7,2 Sans initialisation 3,72 1 nb procs 4 8 16 32 64

36. Evaluation de perf. sur des applications irrégulières Lancer de rayons temps réel avec OVM Code PovRay parallélisé Temps de calcul pour 50 scènes PovRay sur un cluster de PC • Distribution de la scène à tous les processeurs • Découpage en bandes • Calcul pour chaque image des bornes de bandes • pour tous les processeurs

37. Serveurs Client • Chargement scène • Envoi scène au serveurs • Tand qu’il reste des FF à calculer • Calcul d’échange d’énergie • Parcours des hiérarchies • Raffinement (création de liens) • Attente résultats • Fin • Chargement scène • Initialisation • Calcul continu de facteurs de forme  Accélération 100 2000 2001 Bohn/Garmann Singh Carter 1994 10 Benavides OVM Garmann 2000 1 1 2 4 8 16 32 64 128 Nombre de Procs Nouveaux Résultats : Radiosité avec OVM Maître-esclave avec maître participant au calcul

38. Résumé • Il est possible d’écrire des applications parallèles régulières et irrégulières avec OVM • L’environnement OVM est fonctionnel sur les clusters • OVM obtient des performances comparables à MPI sur des applications régulières (test pour différents rapports opérations/communications) • OVM permet d’atteindre des accélérations linéaires sur des applications irrégulières (AIRES, lancé de rayons, radiosité) en conservant une expression « Maître-esclave »

39. Perspectives • Comparaison de performance avec les environnements d’équilibrage de charge comme Athapascan et AMPI. • Adaptation d’OVM pour les architectures à mémoire partagée (Partage des données de l’application et partage des données d’OVM) • Optimisation de la localité des références et comparaison de performance avec SMARTS • Hiérarchisation / extensibilité d’OVM (cluster de multiprocesseurs) • Test sur des applications de tri (PSOP), optimisation combinatoire (branch & bound), calcul creux (Cholesky) • Adaptation OVM-XtremWeb Un environnement bas niveau unique pour une large variété d’applications et d’architectures parallèles

40. Sommaire • Introduction aux Modèles d’exécution • QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP • OVM: un modèle d’exécution pour les applications régulières et irrégulières • XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle • Conclusion et Perspectives

41. AU AU AU AU JP Grilles de calcul et grands systèmes distribués (GRID) Connecter et fédérer des ressources de calcul/stockage/instruments géographiquement distribuées Globalisation des Ressources Informatiques et des Données Apples USA Application-Level Scheduling Bricks USA Performance evaluation for analysis and comparison of various scheduling DOCT USA The Distributed Object Computation Testbed (DOCT) is for handling complex documents Entropia.com USA Desktop software that should provide universal and pervasive source of computing power CERN Data Grid EU middleware for the data-intensive applications Folding@Home USA Covise DE Collaborative, Visualization and Simulation Environment Understanding how proteins self-assemble.   DAS NL Wide-area distributed cluster, parallel and dist. computing EROPPA EU Software to design, implement, and experiments with remote/distributed access to 3D graphic applications GLOBUS USA Basic software infra. for computations that integrate geo. distributed computational and information resources Globe EU Study and implement a unifying paradigm for the large-scale wide area distributed shared objects HARNESS USA Based on PVM. Parallel plug-ins, Peer-to-peer distributed control, and multiple virtual machines JaCo3 EU Java and CORBA Collaborative Env. for Coupled Simulations.. JaWs GR JaWS is an economy-based computing model HTC USA Develop,deploy, and evaluate mechanisms and policies that support high throughput computing MetaMPI DE MetaMPI supports the coupling of heterogeneous MPI METODIS DE Metacomputing Tools for Distributed Systems - A metacomputing MPI for TCP/IP and ATM InfoSpheres USA The Caltech Infospheres Project researches compositional systems, MOL DE Metacomputer OnLine is a toolbox for the coordinated use of WAN/LAN connected systems. Javelin USA Javelin: Internet-Based Parallel Computing Using Java Poznan Metacom. PL Development of tools and methods for metacomputing LEGION USA Object-based metasystem. Transparent scheduling, data management, fault tolerance, site autonomy, WAMM IT WAMM (Wide Area Metacomputer Manager) is a graphical tool, built on top of PVM. NASA IPG USA Testbed that provides access to a grid UNICORE DE The UNiform Interface to Computer Resources allows users to submit jobs to remote high perf. Comp. resources NETSOLVE USA PSE. RPC based client/agent/server system for remote access both hardware and software components DesignDrug Molecular Modelling on Peer-to-Peer Grid PARDIS USA Building PARallel DIStributed applications from CORBA to implement application-level interaction DISCWorld An infrastructure for service-based metacomputing (GridSim) A Java-based Toolkit for Modeling and Simulation of World Wide Grids. WebFlow USA WebFlow can be regarded as a high level, visual user interface and job broker for Globus Nimrod/G A global scheduler for parametric computing WebSubmit USA PSE A Web-based Interface to High-Performance Computing Resources NINF

42. Pourquoi d’intéresser aux grands systèmes distribués Systèmes de Calcul Global Systèmes pair à pair (entre pair) 1 Un très grand nombre de PCs sont connectés sur Internet + Stabilité et performance d’Internet 2 Aspects sociologiques (Partage gratuit de ressources) 3 Maturité des logiciels : langages (Java, Perl, PHP) + Disponibilité en tant que logiciel libre d’applications clés : base de données, serveur web, sécurité (authentification, cryptographie) 4 Démonstration de faisabilité (SETI@home, Napster)

43. Calcul Global Global Computing Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet Client : Lanceur de tâches, ordonnanceur + collect. de résultats Requête Résultat Internet Ou réseau propriétaire Requête Résultat Application(s) Application(s) PC serveur PC serveur • Modèle Client-Serveur inversé : 1 client et n serveurs • L’application exécutée sur les serveurs est fournie par le client • Type de services : principalement calcul distribué (SETI@home)

44. Calcul Global Global Computing Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet • Applications massivement distribuées • SETI@Home, distributed.net, GIMP • Plus de 3 Millions d’utilisateurs, 30 TFLOPS • Projets de Recherche (plate-formes) • Javelin, Bayanihan, JET, Charlotte (fondés sur Java) • XtremWeb (LRI), AppLeS (UCSD) • Projets en cours • Entropia, Parabon, Process Tree, United Devices • Folding@Home, Genome@Home, Xpulsar@Home, • Folderol, Gamma Flux, Exodus, Peer review • Site Web de K. Pearson : http://www.nyx.net/~kpearson/distrib.html

45. Pair à Pair (entre pair) Pas de consensus autour d’une définition. Un système dans lequel toutes les ressources peuvent agir comme des clients, des serveurs et/ou maintiennent le système lui même Gnutella Servent: SERveur et cliENT PC client/serveur PC client/serveur Répertoire de services Internet ou réseau propriétaire Répertoire de services • Le service exécuté par le serveur est proposé par le serveur • Type de services : partage de documents, calcul délocalisé Requête • En principe : X clients, Y serveurs, X=Y Résultat PC client/serveur Systèmes Pair à Pair XtremWeb Mode d’interaction inter-ressource : Toutes les ressources sont à la fois client et serveur (elles peuvent demander et/ou offrir des services) Mode d’organisation du système : Système sans serveur centralisé. Système auto-organisé (découverte de ressources, routage,

46. Pair à Pair (entre pair) Pas de consensus autour d’une définition. Un système dans lequel toutes les ressources peuvent agir comme des clients, des serveurs et/ou maintiennent le système lui même • Applications massivement distribuées • Napster, Gnutella, Freenet, FastTrack, etc. • Nombre d’utilisateurs potentiel ~x Millions, espace de stockage de l’ordre du TeraOctet (beaucoup de redondance) • Projets de recherche (plate-formes) • Globe (Tann.), Cx (Javalin), OceanStore (USA), XtremWeb (LRI), AppLeS (UCSD), • Projets actuels (définition de protocoles) • Cosm, Wos, peer2peer.org, JXTA (sun), PtPTL (intel), • Conférence : O’Reilly, • Livre • Peer to Peer, «Harnessing the Power of Disruptive Technologies » Andy Oram, O’Reilly, Intel ?

47. Projet XtremWeb : Une plate-forme d’expérimentation du calcul global pair à pair Permanents : Cécile Germain, Vincent Néri Doctorants : Gilles Fedak, Oleg Lodygensky (co-encadrés) Sujet de recherche : Un environnement de recherche offrant une image système unique à partir de l’agrégation de ressources faiblement couplées un PC accepte PC Mon PC communications potentielles pour les applications parallèles PC requête PC fournit PC PC System CGP2P accepte PC résultat PC PC Un autre PC PC fournit Collaborations : LAL, INP (IN2P3), IEF, EADS, Université de Tsukuba, IMAG, IRISA, Université de Toronto

48. ArchitectureChoix de conception 1 Infrastructure Centralisé ou distribuée ? • Implémentation actuelle  infrastructure centralisée • Global Computing et Pair à Pair (modèles d’interaction) • 3 entités : client/serveur/worker (volontaire) Serveur XW hiérarchique Cluster de PC Serveur Pair à Pair PC Serveur Calcul global (client) PC Client/worker Internet ou LAN PC Worker PC Worker PC Client/Worker

49. workAlive Protocole de Communication ArchitectureChoix de conception 2 La plupart des systèmes sont protégés par des coupes-feu (firewall). Les requêtes doivent provenir des Workers et NON du serveur de tâches. Bien sur le serveur de tâches doit autoriser les requêtes des Workers et des Clients à traverser son coupe feu. • Un worker s’enregistre auprès du serveur par hostRegister. • Losqu’il est disponible, le worker émet getWork (+ les applis localement dispo.). • Le serveur envoie les paramêtres de tâches (ou un code+ des paramêtres). • Lors du calcul, le worker émet workAlive • Le serveur gère un dépassement de délai (timeout) sur le signal workAlive • A la fin du calcul, le worker envoie ses résultats par workResult Ressource maîtrisée par XW hostRegister Serveur Calcul Global Worker WorkRequest workResult XML RPC et SSL authentification et cryptage

50. SUN 1.2 SUN 1.3 SUN 1.4 IBM 1.3 62,6 Natif Exécution de code natif ou de byte code? ArchitectureChoix de conception 3 Bytecode vs Natif 1311,84 1) Performance 1000 322,78 291,82 Conditions du test : Pentium 4 1,7 Ghz 256Mo. Linux 2.4.2 SciMark2.0: 5 noyaux numériques. 187,98 100 82,46 56,17 151,8 20,78 15,09 18,48 17,04 16,69 12,92 12,77 10 3 Générations de JVM: Sun Jdk 1.2.1 =>compilation à la volée Sun Jdk 1.3.1 => hotspot Sun Jdk 1.4 IBM Jdk 1.3 => -JIT Sélectif 6,36 6,55 5,98 5,87 5,55 5,51 5,5 Temps (sec) 4,74 4,63 3,32 3,41 3,85 3,76 3,69 3,64 bbbbbb 5,55 4,55 3,86 1,87 1,44 2,87 2,8 1 0,78 1,35 0,62 0,1 CG EP FFT SOR MC MatMul LU Linpack Avec le byte code, les performances dépendent fortement de la machine virtuelle disponible sur le Worker Meilleures performances du code natif (écart peu significatif pour qq benchs) 2) Compatibilité avec les codes existants Beaucoup de codes (et surtout en numérique) existent en Fortran et C Beaucoup d’applications propriétaires ne sont disponibles qu’en exécutable