Multithreading et Calcul Haute Performance J-F. Méhaut, R. Namyst INRIA, ReMaP, LIP, ENS Lyon

Au menu Introduction : contexte technologique Nouvelles archis: processeurs, réseaux, etc. Multithreading : quels intérêts? Définition, premiers contacts, partage mémoire Pause (10’) Multithreading distribué Intérêts et difficultés Quelques environnements L’environnement PM2 Conclusion

Introduction

Architecture processeur Cray-TERA Applications 1 2 3 4 i=1 i=2 i=3 i=n … F (a) j=1 j=2 G(A) F (b) Threads concurrents j=3 … j=m Programme séquentiel Streams Pool d’instructions prêtes Pipeline d’instructions en cours d’exécution

Multi-threading Cray-TERA Principe Maintenir plusieurs threads (streams) actifs (40 à 80 streams => 90% utilisation de la machine) Garantir une instruction prête à chaque cycle processeur Dispositif matériel supportant Gestion de plusieurs streams Changement de contexte tous les cycles (3ns) Jusqu’à 8 requêtes d’accès mémoire en attente pour un stream

Caractéristiques du processeur Cray-TERA Horloge 333 MHZ Accès mémoire 2,8 Gbytes/seconde bande passante Emission/réception d’un paquet par cycle Pas de cache de données, cache instr 2Mbytes Multiprogrammation/concurrence 16 domaines de protection 128 streams (32 registres, 1 Program Counter)

Enjeux Trouver le bon niveau de parallélisme Marché restreint Besoin de travail (threads) pour saturer la machine Quatre sources potentielles de parallélisme Applications (jobs) Threads Boucles ILP (Instruction-Level Parallelism) Compilateur/paralléliseur Marché restreint Une machine installée à San Diego

Cluster computing Architecture homogène, faiblement hétérogène Grappes (Cluster, COW), machines // PC, stations de travail SCI, Myrinet, Giganet, MPC, ... Protocoles de communication BIP, SISCI, SciOS, VIA, TCP, UDP, ... Myrinet/BIP PC Commutateur

Motivations pour le haut-débit Performances des communications Atteindre le niveau de performance des machines parallèles avec les équipements du marché (PC ou station de travail) Minimiser la latence, maximiser le débit Thématiques de recherche Matériel Commutateurs, cartes d’interface Commutations, routage Logiciel Interfaces de communication (AM, FM, BIP, …) Env. de programmation (MPI, PM2, Nexus,…)

Myrinet Objectifs Caractéristiques Performances en communication équivalentes à celles des supercomputers Quelques microsecondes en latence Atteindre le Gbps en bande passante Caractéristiques Carte d’interface programmable Protocole : carte d’interface et le host Utilisé pour implémenter des environnements de programmation

Myrinet : Description technique Myrinet commutateur Host Carte d’interface Câble 2,6 Gbps full duplex Crossbar complet Routage Statique à la source (entête consommé progressivement) Wormhole

Myrinet : cartes d’interface Matériel 66MHz cpu (LANai) 1 Mbyte SRAM 3 DMA (lien entrée, lien sortie, mémoire du host) Interface au bus PCI Logiciel LANai Control Program (LCP) Lien Myrinet RISC Packet Interface DMA Controler PCI Bridge PCI Bus LANai Memory Performance (BIP/Myrinet) 6 microsecondes latence 127 Mbytes/sec bande passante

SCI*(Scalable Coherent Interface) Réseau à capacité d’adressage Adressage des mémoires distantes Lecture/écriture distante sans interruption du processeur distant Support matériel pour mémoire partagée * Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)

SCI : caractéristiques techniques Scalable Coherent Interface Matériel standard (PC, station Unix, …) Architecture en anneau et/ou commutateur Evolutif jusqu’à 64 Knœuds Bande passante de 500 Mo/s (4 Gb/s) full-duplex Pas de cohérence sur PCI (bus d’entrées/sorties) * Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)

SCI : performances Latence : 2.5 ms (écriture de processus à processus) Débit : 70 Mo/s Verrou : < 10 ms (fetch&add)

Comms : remarques préliminaires Règle des 80/80 80% des messages sont de taille inférieure à 256 octets 80% du trafic provient de messages d’une taille supérieure à 8KB Nouvelles approches Latence faible pour les petits messages Bande passante importante pour les gros messages Coût des protocoles traditionnels

Protocole système (TCP/UDP/IP) Communications système Evolutions technologiques Coûts logiciels des protocoles Protocole système (TCP/UDP/IP) Réseaux 10 Mb Réseaux 100 Mb Réseaux Gb

Comm. en contexte utilisateur Recherches académiques Active Messages (Berkeley) Illinois Fast Messages (Urbana) U-Net (Cornell) MPC (Paris6, Versailles) BIP (Lyon) Interface de bas-niveau Cibles pour les supports d’exécution Standard industriel : VIA Participation des industriels Etendre le spectre des applications Processus OS Interface

VI User Agent (“libvia”) VIA : Virtual Interface Architecture VI Consumer Sockets, MPI, Legacy, etc. Host VI User Agent (“libvia”) VI Kernel Agent (Slow) User-Level (Fast) Descriptor Read, Write VI C S COMP R Undetermined Open, Connect, Map Memory Doorbells Requests Completed NIC VI-Capable NIC

Giganet : Cartes VIA Fast Fastest Application With VIA 50 versus 7000 TCP/IP Winsock API Fast NDIS VI API Fastest Application Native VI Interface With VIA 50 versus 7000 instructions

™ Commutateurs Cartes d’interface Administration du réseau cLAN pour Windows cLAN pour Linux

Supports d’exécution parallèle Avantages pour les utilisateurs Abstractions de haut niveau Portabilité des applications Efficacité ! Applications Interface de programmation (API) Support d’exécution // Systèmes d’exploitation Architectures parallèles et distribuées

Le multithreading : quel(s) intérêt(s) ? Introduction et rappels

Rappel : les processus lourds Caractéristiques Entité active directement supportée par l’OS Flot d’exécution Espace d’adressage privé Ressources systèmes Exécution séquentielle Coût de gestion élevé Allocation des ressources Appels systèmes

Processus lourds (bis) Ressources “kernel” + données “user” Espace utilisateur Processus Processus Processus Ordonnanceur Noyau processeur

Threads : Motivations Difficulté de programmation Performances Fil d’exécution unique  une seule chose à la fois ! Partage de données laborieux Performances Opérations de base coûteuses Recouvrement des opérations d’E/S difficiles

Simplicité de programmation Objectif Mener plusieurs activités indépendantes au sein d’un processus Exemples Simulations Serveurs de fichiers Systèmes d’exploitation (!) Seule solution (?) Automate à états finis implanté « à la main » (sauvegardes d’états)

Structure d’un OS monolytique Exemple Séquence infinie d’opérations courtes Ordre et fréquence des scrutations ? for (;;) { if(networkMsgIn()) getNetworkMsg(); if(kbdReady()) getKey(); if(diskBlockReady()) handleDiskBlock(); … }

Systèmes multiprogrammés Exécution indépendante des activités Concurrence entre les différents traitements for (;;) { wait for key stroke; getKey(); } for (;;) { wait for network msg; getNetworkMsg(); } for (;;) { wait for disk block; handleDiskBlock(); }

Processus serveur classique Sérialisation des requêtes Pas de recouvrement des E/S Exploitation SMP délicate Prise en compte de priorités ? client serveur OS OS

Sur l’efficacité des E/S Caractéristiques du serveur de fichiers Tps de traitement d’une requête = 15ms Tps supplémentaire pour l’accès disque = 75ms (pour 1/3 des requêtes) Débit sans/avec recouvrement des E/S Sans recouvrement 25 requêtes/seconde Avec recouvrement 33.33 requêtes/seconde (+33%)

Les processus légers Principe Détacher flot d’exécution et ressources Introduits dans divers langages & systèmes Programmation concurrente Recouvrement des E/S Exploitation des architectures SMP thread ressources

Caractéristiques de base Thread = pile + contexte Partage de ressources Code, tas, … : espace d’adressage Fichiers ouverts Table des traitants de signaux Opérations de base performantes Création, destruction Synchronisation, commutation de contextes Création d’un processus léger Adresse de fonction à exécuter + paramètres

Performance des threads Opérations critiques Création/destruction (gestion mémoire) Changement de contexte (temps-partagé) Synchronisation (mode utilisateur) Programme d’évaluation Création d’une activité (processus, thread) + synchronisation (terminaison de l’activité) OS/Processeur Processus Thread noyau Thread utilisateur PM2 Linux 2.2/PII 450 0.540 0.130 - 0.006 Solaris 2.7/PII 350 8.622 0.214 0.160 0.009

Repères historiques L’ancêtre : les coroutines Entrelacement explicite des exécutions Langages : Simula (67), Modula2 (82) Primitives clés : create + resume Les threads dans les systèmes Cthread (Mach) -> DecThread -> PThread (~90) Chorus, Solaris (87), winNT, IRIX, Linux, etc. Les threads dans les langages Ada (83), Java, etc. C++ //, Eiffel //, etc.

Le multithreading : quel(s) intérêt(s) ? Premier contact

L’interface POSIX-Threads Interface de programmation standard pour Unix Portabilité des applications Solaris, IRIX, HP-UX, Linux, etc. Fonctionnalités Création/destruction de threads Synchronisation Ordonnancement, priorités Signaux Etc.

Exemple: création Création d’un nouveau thread Éventuels attributs dans la structure attr Exécution de start_func avec le paramètre arg *pid est l’identificateur du thread créé int pthread_create( pthread_t *pid, pthread_attr_t *attr, void * (*start_func)(void *), void *arg);

Attente de fin d’exécution Attente de la terminaison du thread pid Récupération de son code de retour status On peut contourner ce mécanisme en « détachant » les threads : int pthread_join( pthread_t pid, void **status); int pthread_detach( pthread_t pid);

« Hello World! » #include <stdio.h> #include <pthread.h> void *func(void *arg) { printf(“Thread %x says %s\n”, pthread_self(), arg); return NULL; } int main(void) pthread_t pid; pthread_create(&pid, NULL, func, “Hello World!”); printf(“This is the main thread\n”); pthread_join(pid, NULL); return 0;

Attributs Ensemble fixé de caractéristiques Threads Verrous Utilisé à l’initialisation Threads, verrous, variables de condition, etc. Threads Priorité Pile : taille, emplacement Détaché : oui/non Type d’ordonnancement Verrous Inversion de priorités, récursivité

Attributs : exemple #include <stdio.h> #include <pthread.h> void *handle_request(void *arg) { … } int main(void) { … pthread_attr_t attr; for(;;) { fd = accept(sock, …); pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); pthread_create(NULL, &attr, handle_request, fd);

Exemple bis : pile À manipuler avec précaution ! Quelle taille de pile choisir ? Comment prévenir/détecter les débordements ? pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 128*1024); pthread_create(NULL, &attr, func, NULL);

Le standard OpenMP Interface pour écrire des applications multithreads portables (sur SMP) Directives de compilation (C, C++, Fortran) + routines Objectif = simplicité + portabilité Constructeurs + fabricants de logiciels + etc. Modèle de programmation « Fork-Join » Parallélisation des boucles (#pragma omp)

Le multithreading : quel(s) intérêt(s) ? Partage mémoire efficace

Les threads et la mémoire Chaque thread possède sa propre pile Variables locales « privées » ( visibilité) Les threads partagent l’espace d’adressage Variables globales Tas (malloc) Variables locales (piles) également ! Intérêt Communications par pointeurs ! Parallélisation de programmes séquentiels aisée ?

Problèmes de réentrance Exemple simple : int glob = 0; void *inc(void *arg) { int i; for(i=0; i<100; i++) glob++; } int main(void) { pthread_create(&t1, NULL, inc, NULL); pthread_create(&t2, NULL, inc, NULL); pthread_join(t1, NULL); pthread_join(t2, NULL); printf(“glob = %d\n”, glob); Résultat ?

Explication glob++ n’est pas forcément une opération atomique Scénario d’exécution concurrente par 2 threads : Mov @glob, $r1 ; charger Inc r1 ; incrémenter Mov $r1, @glob ; enregistrer Mov @glob, $r1 Inc r1 Mov @glob, $r1 Inc r1 Mov $r1, @glob … Mov $r1, @glob Mov @glob, $r1 Inc r1 Mov @glob, $r1 Inc r1 Mov $r1, @glob … Mov $r1, @glob

Outils pour la synchronisation Exclusion mutuelle : les verrous Synchronisations plus complexes : Variables de condition (cf moniteurs de Hoare) pthread_cond_wait pthread_cond_signal, pthread_cond_bcast int glob = 0; void *inc(void *arg) { for(i=0; i<100; i++) { pthread_mutex_lock(&mutex); glob++; pthread_mutex_unlock(&mutex); }

Code réentrant « code demeurant correct lorsqu’il est exécuté simultanément par plusieurs threads » Exemples typiques Fonction n’utilisant que des variables locales Code protégé par un verrou Quid du code que l’on écrit pas soi-même ? Malloc, free, …, la bibliothéque standard Fonctions « MT-safe » Option –D_REENTRANT Certains prototypes changent…

Importance de la synchro. Cohérence séquentielle de la mémoire ? Compilateurs/Optimiseurs Instructions réordonnées Processeurs modernes Ecritures réordonnées On ne peut pas supposer l’ordre des écritures Primitives de synchronisation Agissent comme des « barrières mémoire »

Variables spécifiques Pb : comment gérer les variables globales « privées » int my_x; void g(void) { …my_x… } void f(void) my_x = do_compute(); … g();

Variables spécifiques Principe Variable accessible à partir d’une clé Allocation globale (souvent à l’initialisation) pthread_setspecific(clé, valeur) pthread_getspecific(clé) -> valeur Exemple : la variable errno Fichier errno.h #ifdef _REENTRANT #define errno (*__errno_location()) #else extern int errno; #endif

A propos d’efficacité Les threads sont-ils toujours meilleurs que MPI sur architectures SMP ? Solution « processus communicants » Communications pénalisantes (copies) Surcoût en utilisation de ressources Recouvrement plus difficile Solution « processus légers » Synchronisations additionnelles Accès aux variables spécifiques coûteux

Le multithreading : quel(s) intérêt(s) ? Ordonnancement des threads

Multithreading utilisateur Deux ordonnanceurs indépendants : User Space Process Scheduler Scheduler OS Kernel processor

Multithreading noyau Un seul ordonnanceur : User Space Process Scheduler OS Kernel processor

Multithreading mixte Deux ordonnanceurs coopérants User Space Process Scheduler Scheduler OS Kernel processor Note: Quid des appels systèmes bloquants ?

Ordonnancement non-préemptif Le processus cède la main Lorsqu’il se bloque Lorsqu’il meurt Avantages Peu de commutations de contextes Atténuation des problèmes de réentrance Inconvénients Partage non-équitable des ressources Risque de famines

Ordonnancement préemptif Une horloge force les commutations Avantages cf. inconvénients du non-préemptif Inconvénients cf. avantages du non-préemptif En général Threads noyaux  préemptif Threads utilisateurs  non-préemptif

Choix de l’ordonnancement Niveau d’ordonnancement pthread_attr_setscope(…) PTHREAD_SCOPE_SYSTEM PTHREAD_SCOPE_PROCESS Classes d’ordonnancement pthread_attr_setschedpolicy(…) SCHED_FIFO SCHED_RR SCHED_OTHER

Le multithreading : quel(s) intérêt(s) ? Recouvrement des Entrées/Sorties

Recouvrement des E/S Au lieu de …on voudrait : Temps CPU perdu CPU utilisé syscall Espace utilisateur I/O request interrupt Espace noyau Matériel …on voudrait : Espace noyau Espace utilisateur Matériel

E/S et ordonnancement Threads noyaux : OK Threads utilisateurs Appel bloquant -> blocage du processus entier Threads mixtes Idem au bout d’un certain nombre ! Solutions ? Appels toujours non-bloquants (polling) Appels effectués par des threads dédiés Support système spécifique

Scheduler Activations Introduit par [Anderson et al. 91] Idée: la coopération entre les deux ordonnanceurs est bidirectionnelle L’ordonnanceur utilisateur utilise des appels systèmes L’ordonnanceur noyau utilise des upcalls! Upcalls Informe l’application des événements noyaux Activations Autant d’activations en exécution que de processeurs Contrôlées par le noyau Principe mis en œuvre dans Solaris

Multithreading Distribué Principe et Enjeux

Principe Introduire les threads dans les applications distribuées proc proc proc proc réseau

Enjeux « Bénéfices » escomptés Recouvrement naturel des communications Meilleur support du parallélisme à grain fin Uniformisation de la configuration machines monoprocesseur/machines SMP Virtualisation de l’architecture threads = processeurs virtuels cible pour des compilateurs (ex: HPF) équilibrage de charge générique et transparent Meilleure réactivité au réseau Exécution distribuée de langages multithreads

Virtualisation Objectif Intérêts Machine constituée de centaines de processeurs virtuels Intérêts Applications s’adaptant à la configuration Passage à l’échelle (scalability) Équilibrage de charge possible par migration de threads Équilibrage dynamique Régulateur indépendant de l’application !

Virtualisation : contraintes Exécution indépendante à la localisation Problème des E/S délicat Communications par mémoire partagée Mémoire virtuellement partagée nécessaire Compatible avec les threads ! Difficile sur architecture hétérogène Architecture hétérogène Migration des threads prohibitive

Meilleure réactivité au réseau Illustration : MPI et les communications asynchrones MPI_Isend MPI_recv Acquittement MPI_test Processus A Processus B

Multithreading Distribué Quel modèle de programmation ?

Approche par juxtaposition Principe : pas de modèle ! Simplement utiliser conjointement Une bibliothèque de communication (ex: MPI) Une bibliothèque de multithreading Problèmes Conceptuels Pas de visibilité globale des threads Sémantique des communications ? Techniques Compatibilité entre les bibliothèques Travail d’intégration spécifique -> non réutilisable

Threads communicants Principe Exemples Envoi de message entre threads Modèle « MPI-like » Modèle « Acteurs » Nommage Nommage global des threads Ports de communication Exemples Chant (M. Haines, ICASE) Athapascan-0b (J. Briat, INRIA Grenoble)

Modèle Pthreads étendu Principe Threads + primitives étendues Create/Join à distance Synchronisations distribuées Particularités Nommage global des threads Restriction du modèle Pthreads Exemples Chant (M.Haines, ICASE), Rthreads (M. Zahn, Allemagne)

Modèle Pthreads distribué Principe Adaptation complète (?) de Pthreads Threads + mémoire virtuellement partagée Transparence Cohérence assurée lors des défauts de pages Restriction sur les E/S Extensions Cohérences mémoires relâchées Exemple DSM-Threads (F. Mueller, Berlin)

Modèle dérivé des RPC Principe Exemples Appel de procédure à distance (A. Birell) Extension du concept aux threads Création de threads pour exécuter les procédures Désignation globale des services Numéro  fonction Souches (stubs) pour la transmission des paramètres Exemples Nexus (I. Foster, Argonne), PM2

Multithreading Distribué Intégration des threads et des communications

Progression des communications Problème Comment assurer la progression des communications ? proc proc proc proc réseau

Scrutation et interruptions La scrutation est nécessaire API réseau ne fournissant pas d’appels bloquants OS ne fournissant pas “d’activations” Problème Fréquence difficile à assurer Coûteux en présence de multiple “pollers ” Les interruptions sont nécessaires Réactivité Outils de synchronisation “interrupt safe” ?

Scrutation par l’ordonnanceur  Création d’une catégorie de polling (ex: MPI), assignation d’une fréquence et enregistrement de callbacks. Polling jobs queue  Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque. MPI_Isend Marcel_poll MPI_Irecv Marcel_poll MPI Polling( ) callback callback  Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur... Ordonnanceur des threads

Multithreading Distribué L’environnement PM2

Premières réflexions sur PM2 Parallel Multithreaded Machine (R. Namyst) Virtualisation de l’architecture Régulateurs génériques de charge (Y. Denneulin) Plateformes usuelles (COW, NOW), machines parallèles Distribution du logiciel, assistance, documentation:-( InterPRC Stratagème (C. Roucairol) Applications irrégulières Optimisation combinatoire Algèbre linéaire creuse (J. Roman) Ordonnancement, régulation Fortement irrégulière : placement + migration

Projet PM2 (95-xx) Objectif ambitieux : virtualisation Propositions Indépendance de la machine cible (#processeurs) Degré de parallélisme important (#processus) Parler de “traitement” / “processus” mécanismes de décomposition parallèle Propositions Mécanisme de décomposition Appel de procédure à distance léger (LRPC) Support des activités Processus légers (threads) Régulateur dynamique de charge Placement + Migration

Appel de procédure à distance PM2 PM2 LRPC Différentes déclinaisons Synchrone Attente différée Asynchrone Nos concurrents... Nexus : RSR Athapascan : appels de service

Hello World! #include <pm2.h> unsigned SAMPLE; void sample_func(void) { char msg[128]; pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128); pm2_rawrpc_waitdata(); printf(“%s\n”, msg); } void main(int argc, char **argv) { int module[MAX_MODULES], nb_modules; pm2_rawrpc_register(&SAMPLE, sample_func); pm2_init(&argc, argv, 2, module, &nb_modules); if(pm2_self() == les_modules[0]) { pm2_rawrpc_begin(module[1], SAMPLE, NULL); pm2_pack_byte(SEND_CHEAPER, RECV_CHEAPER, “Hello World!”, 128); pm2_rawrpc_end(); pm2_kill_modules(module, nb_modules); pm2_exit();

Threaded “Hello world!” Création d’un thread Obligatoirement par pm2_thread_create positionnement d’un certain nombre d’attributs héritage du “droit” de faire unpack ... void thread_func(void *arg) { char msg[128]; pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128); pm2_rawrpc_waitdata(); printf(“%s\n”, msg); } void sample_func(void) { pm2_thread_create(thread_func, NULL);

Mobilité des activités Migration de processus légers PM2 PM2 Pourquoi ? Régulation de charge Localité des données Comment ? Transfert du contexte Programmes SPMD

PM2 : architecture logicielle Applications Régulation HPF, C* C++//, Java Interface de programmation (RPC, migration, allocation iso-adresse) Marcel PM2 Madeleine Unix (~10 versions) Architecture (grappes, machines parallèles) Légende Marcel : noyau de processus légers Madeleine : module de communication

Marcel : des processus légers Multiprogrammation spécialisée pour PM2 Sous-ensemble de POSIX + extensions Support pour la migration Sérialisation des piles de threads Allocation des piles (Iso-Malloc, [Antoniu99]) Gestion mémoire optimisée (cache de piles) Deux niveaux de threads (noyau et utilisateur) Support des machines SMP Efficacité proche du niveau utilisateur Exploitation des Scheduler Activations sous Linux Appels systèmes bloquants (Danjean00)

Marcel: Implantation SMP Taille du pool de threads noyaux Automatique / option en ligne de commande Ordonnancement Round-Robin sur chaque LWP Placement sur les LWP paramétrable marcel_attr_init(&attr); marcel_attr_setschedpolicy(&attr, MARCEL_SCHED_FIXED(2)); marcel_create(&pid, &attr, func, arg); ...

Marcel : performances Comparatif avec d’autres bibliothèques OS/Processeur Processus Thread kernel Thread user Marcel Linux 2.2 / PII 450 0.540 0.130 - 0.006 Solaris 2.7/ PII 350 8.622 0.214 0.160 0.009 Performances brutes (meilleur cas) Opération Version « mono » Version « SMP » Chgt contexte 125 ns 212 ns Création seule 536 ns 1 us Création + termin. 833 ns 3 us Arbre de threads 1.232 ms 6.986 ms

Madeleine : objectifs Supports des différents protocoles Système (TCP, MPC) Haut-niveau (MPI, PVM) Bas-niveau (BIP, SISCI, VIA,…) Protocoles multi-paradigmes VIA : message-passing, remote DMA SCI : shared memory, DMA SBP : tampons statiques Protocoles multi-modes BIP : messages courts, longs

Madeleine : communications LRPC, Migration Madeleine Interface de programmation Couche de portabilité MPI, PVM, TCP, UDP, BIP, SISCI, VIA, SHMEM

Packing - Unpacking Commandes: Modes: Mad_pack(cnx, buffer, len, pack_mode, unpack_mode) Mad_unpack(cnx, buffer, len, pack_mode, unpack_mode) Modes: Send_SAFER Send_CHEAPER Send_LATER Receive_EXPRESS Receive_CHEAPER

Emission : modes d’empaquetage Send_SAFER Send_LATER Send_CHEAPER Pack Modification End_packing ? Version transmise

Réception : mode de déballage (1) RECV_EXPRESS Unpack Tampon Après Unpack Données disponibles End_packing

Réception : mode de déballage (2) RECV_CHEAPER Unpack Tampon Après Unpack Données disponibles ??? End_packing Données disponibles

Exemple: Protocole BIP/Myrinet Processus A Réseau Processus B Message Entête Vecteur Acquittement DMA

Madeleine sur BIP/Myrinet Communication contexte utilisateur (L. Prylli) Zéro copie Contrôle de flux pour les petits messages Madeleine/BIP Latence : 8 µs Débit : 125 Mo/s Migration PM2 : 52 µs

Madeleine : résultats Performances en latence Migration PM2 6 µs sur SISCI/SCI 8 µs sur BIP/Myrinet Migration PM2 24 µs sur SISCI/SCI 52 µs sur BIP/Myrinet Performance en bande passante 125 Mo/s sur BIP/Myrinet World record

Madeleine : d’autres utilisations Bus CORBA haute performance Collaboration avec Alcatel-INRIA Communications ORB efficaces Zéro copie avec un ORB? Intégration thread et communication (réactivité) Support du multiprotocoles MPI-Madeleine Collaboration avec L. Prylli (LIP) Implémentation MPI

Compilation/exécution d’un programme PM2 Fabrication d’un profil Paramétrage de l’environnement make xconfig (pm2, debug, madeleine, protocole, marcel, mono-smp) Géneration d’une flavor Sélection du profil setenv PM2_FLAVOR=mon_profil Compilation du programme make Choix d’une configuration pm2conf myri0 myri1 myri2 Exécution du programme pm2load programme arg1 arg2 … argn

DSM-PM2 : mémoire partagée et multithreading Generic, configurable Support for multiple consistency models Multi-protocol support for a given consistency model User interface : protocol selection/specification initial distribution of DSM pages Thread migration Integrated in consistency protocols Support for adaptive protocols: page migration vs. thread migration

Compilation HPF/C* sur PM2 Equilibrage dynamique dans HPF/C* (C. Pérez) Modification des exécutifs des compilateurs Module générique d’équilibrage de charge Simulation de flamme Align Disribute Processors Threads PM2

Compilation et PM2 (suite) Projet Hyperion (New Hampshire) Machine virtuelle Java distribuée Thread Java calqués sur les threads PM2 Mémoire partagée reposant sur DSM-PM2 Grappes de PC Projet Paris (Rennes) Utilisation de Madeleine (Y. Jégou) MOME, DSM pour un compilateur HPF Projet NANOS (Barcelone) Environnement pour machines SMP à l’origine Portage sur PM2 et DSM-PM2 OpenMP

Lancer de rayons // (PM2) Transfert technologique (TTN ProHPC) Société AGEMOB Rendu 3D réaliste de mobilier Serveur de calcul pour des chaines de distribution Projet MOB3D : LIP + AGEMOB + fabricants de meuble Calcul rapide d’une image réaliste sur réseau de stations POV-Ray (Persistance Of Vision Ray-tracer) Domaine public, portabilité (Unix, NT) Assez largement utilisé dans la communauté PM2POVRAY Application parallèle exploitant des grappes de SMP

Principe de PM2POV-Ray Scène répliquée sur chaque machine Découpage de l’image en threads Régulation de charge Distribution cyclique des threads sur les machines Equilibrage dynamique par migration P0 P1 P2 P3

Conclusions Efficacité et portabilité Des collaborations Bon compromis obtenu pour PM2 Des collaborations Principalement pour des compilateurs et bibliothèques Stages DEA-DESS, thèse Disponible sur Internet http://www.pm2.org Collaborations industrielles Microsoft, Alcatel Aérospatiale-Matra (caches Web)