La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Multithreading et Calcul Haute Performance J-F. Méhaut, R. Namyst INRIA, ReMaP, LIP, ENS Lyon."— Transcription de la présentation:

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

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

3 Introduction

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

5 Multi-threading Cray-TERA uPrincipe  Maintenir plusieurs threads (streams) actifs (40 à 80 streams => 90% utilisation de la machine)  Garantir une instruction prête à chaque cycle processeur uDispositif 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

6 Caractéristiques du processeur Cray-TERA u Horloge  333 MHZ u 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 u Multiprogrammation/concurrence  16 domaines de protection  128 streams (32 registres, 1 Program Counter)

7 Enjeux uTrouver le bon niveau de parallélisme  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 uMarché restreint  Une machine installée à San Diego

8 Cluster computing uArchitecture 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

9 Motivations pour le haut-débit uPerformances 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 uThématiques de recherche  Matériel Ù Commutateurs, cartes d’interface Ù Commutations, routage  Logiciel Ù Interfaces de communication (AM, FM, BIP, …) Ù Env. de programmation (MPI, PM2, Nexus,…)

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

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

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

13 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)

14 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)

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

16 Comms : remarques préliminaires u 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 u Nouvelles approches  Latence faible pour les petits messages  Bande passante importante pour les gros messages  Coût des protocoles traditionnels

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

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

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

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

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

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

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

24 Rappel : les processus lourds u 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 u Coût de gestion élevé  Allocation des ressources  Appels systèmes

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

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

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

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

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

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

31 Sur l’efficacité des E/S u 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) u Débit sans/avec recouvrement des E/S  Sans recouvrement Ù 25 requêtes/seconde  Avec recouvrement Ù requêtes/seconde (+33%)

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

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

34 Performance des threads u Opérations critiques  Création/destruction (gestion mémoire)  Changement de contexte (temps-partagé)  Synchronisation (mode utilisateur) u Programme d’évaluation  Création d’une activité (processus, thread) + synchronisation (terminaison de l’activité) OS/ProcesseurProcessusThread noyauThread utilisateurPM2 Linux 2.2/PII Solaris 2.7/PII

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

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

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

38 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);

39 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);

40 « Hello World! » #include 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; }

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

42 Attributs : exemple #include 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); }

43 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 );

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

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

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

47 Problèmes de réentrance u 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 ?

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

49 Outils pour la synchronisation u Exclusion mutuelle : les verrous u 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); }

50 Code réentrant u «code demeurant correct lorsqu’il est exécuté simultanément par plusieurs threads » u Exemples typiques  Fonction n’utilisant que des variables locales  Code protégé par un verrou u 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…

51 Importance de la synchro. u 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 u Primitives de synchronisation  Agissent comme des « barrières mémoire »

52 Variables spécifiques u 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(); }

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

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

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

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

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

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

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

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

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

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

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

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

65 Scheduler Activations u Introduit par [Anderson et al. 91] u 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! u Upcalls  Informe l’application des événements noyaux u Activations  Autant d’activations en exécution que de processeurs  Contrôlées par le noyau u Principe mis en œuvre dans Solaris

66 Multithreading Distribué Principe et Enjeux

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

68 Enjeux u « 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

69 Virtualisation u Objectif  Machine constituée de centaines de processeurs virtuels u 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 !

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

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

72 Multithreading Distribué Quel modèle de programmation ?

73 Approche par juxtaposition u Principe : pas de modèle !  Simplement utiliser conjointement Ù Une bibliothèque de communication (ex: MPI) Ù Une bibliothèque de multithreading u 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

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

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

76 Modèle Pthreads distribué u 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 u Exemple  DSM-Threads (F. Mueller, Berlin)

77 Modèle dérivé des RPC u Principe  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 u Exemples  Nexus (I. Foster, Argonne), PM2

78 Multithreading Distribué Intégration des threads et des communications

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

80 Scrutation et interruptions u 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 ” u Les interruptions sont nécessaires Ù Réactivité  Problème Ù Outils de synchronisation “interrupt safe” ?

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

82 Multithreading Distribué L’environnement PM2

83 Premières réflexions sur PM2 uParallel 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:-( uInterPRC 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

84 Projet PM2 (95-xx) uObjectif ambitieux : virtualisation  Indépendance de la machine cible (#processeurs)  Degré de parallélisme important (#processus)  Parler de “traitement” / “processus” Ù mécanismes de décomposition parallèle uPropositions  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

85 Appel de procédure à distance uDifférentes déclinaisons  Synchrone  Attente différée  Asynchrone PM 2 LRPC uNos concurrents...  Nexus : RSR  Athapascan : appels de service

86 Hello World! #include 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(); }

87 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); }...

88 Mobilité des activités uMigration de processus légers PM 2 uPourquoi ?  Régulation de charge  Localité des données uComment ?  Transfert du contexte  Programmes SPMD

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

90 Marcel : des processus légers uMultiprogrammation 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) uDeux 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)

91 Marcel: Implantation SMP u Taille du pool de threads noyaux  Automatique / option en ligne de commande u 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);...

92 Marcel : performances u Comparatif avec d’autres bibliothèques u Performances brutes (meilleur cas) OpérationVersion « mono »Version « SMP » Chgt contexte125 ns212 ns Création seule536 ns1 us Création + termin.833 ns3 us Arbre de threads1.232 ms6.986 ms OS/ProcesseurProcessusThread kernelThread userMarcel Linux 2.2 / PII Solaris 2.7/ PII

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

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

95 Packing - Unpacking Commandes: 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

96 Emission : modes d’empaquetage Version transmise Pack Modification End_packing Send_SAFERSend_LATERSend_CHEAPER

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

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

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

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

101 Madeleine : résultats uPerformances en latence  6 µs sur SISCI/SCI  8 µs sur BIP/Myrinet uMigration PM2  24 µs sur SISCI/SCI  52 µs sur BIP/Myrinet uPerformance en bande passante  125 Mo/s sur BIP/Myrinet World record

102 Madeleine : d’autres utilisations uBus 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 uMPI-Madeleine  Collaboration avec L. Prylli (LIP)  Implémentation MPI Ù Intégration thread et communication (réactivité) Ù Support du multiprotocoles

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

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

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

106 Compilation et PM2 (suite) uProjet 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 uProjet Paris (Rennes)  Utilisation de Madeleine (Y. Jégou) ÙMOME, DSM pour un compilateur HPF uProjet NANOS (Barcelone)  Environnement pour machines SMP à l’origine  Portage sur PM2 et DSM-PM2  OpenMP

107 Lancer de rayons // (PM2) uTransfert 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 uPOV-Ray (Persistance Of Vision Ray-tracer)  Domaine public, portabilité (Unix, NT)  Assez largement utilisé dans la communauté uPM2POVRAY  Application parallèle exploitant des grappes de SMP

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

109 Conclusions uEfficacité et portabilité  Bon compromis obtenu pour PM2 uDes collaborations  Principalement pour des compilateurs et bibliothèques  Stages DEA-DESS, thèse uDisponible sur Internet  uCollaborations industrielles  Microsoft, Alcatel  Aérospatiale-Matra (caches Web)


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

Présentations similaires


Annonces Google