Form Hybride Proj

Programmation hybride MPI-OpenMP
Pierre-Francois.Lavallee@idris.fr Philippe.Wautelet@idris.fr
CNRS IDRIS
Version 1.10 16 septembre 2013
P.-Fr. Lavalle P. Wautelet (IDRIS)
Programmation hybride
16 septembre 2013
1 / 234
Disponibilit et mise jour
Ce document est amen tre remis jour rgulirement. La version la plus rcente est disponible sur le serveur web de lIDRIS, rubrique Supports de cours : https://cours.idris.fr
IDRIS - Institut du dveloppement et des ressources en informatique scientique Rue John Von Neumann Btiment 506 BP 167 91403 ORSAY CEDEX France http://www.idris.fr
16 septembre 2013
2 / 234
Sommaire I
1 2
Prambule Introduction Loi de Moore et consommation lectrique Le memory wall Du ct des supercalculateurs Loi dAmdahl Loi de Gustafson-Barsis Consquences pour les utilisateurs Evolution des mthodes de programmation Prsentation des machines utilises MPI avanc Introduction Historique Facteurs inuenant les performances MPI Communications MPI
Types de communications MPI Modes denvoi pour les communications point point Communications collectives Communications mmoire mmoire (RMA) Communications persistantes
Recouvrement calculs-communications Types drivs

P.-Fr. Lavalle P. Wautelet (IDRIS) Programmation hybride 16 septembre 2013 3 / 234
Sommaire II
Equilibrage de charge Placement des processus
4
OpenMP avanc Introduction Limitations dOpenMP Approche classique Fine-grain (FG) Approche Coarse-grain (CG) CG vs. FG : surcots du partage du travail CG Impact au niveau du code source CG Synchronisations nes Performances compares MPI/OpenMP-FG/OpenMP-CG Conclusion Programmation hybride Dnitions Raisons pour faire de la programmation hybride Applications pouvant en tirer parti MPI et le multithreading MPI et OpenMP Adquation larchitecture : laspect gain mmoire Adquation larchitecture : laspect rseau Etude de cas : Multi-Zone NAS Parallel Benchmark
Sommaire III
Etude de cas : Poisson3D
Introduction loptimisation de codes Prsentation de Poisson3D Poisson3D sur Babel
Etude de cas : HYDRO
Outils SCALASCA TAU TotalView
Travaux pratiques TP1 MPI HYDRO TP2 OpenMP Nid de boucles double dpendance TP3 OpenMP HYDRO TP4 Hybride MPI et OpenMP Barrire de synchronisation TP5 Hybride MPI et OpenMP HYDRO
16 septembre 2013
5 / 234
Prambule
16 septembre 2013
6 / 234
Prsentation de la formation Lobjet de cette formation est de faire une prsentation de la programmation hybride, ici MPI+OpenMP, ainsi quun retour dexpriences dimplmentations effectives dun tel modle de paralllisation sur plusieurs codes applicatifs. Le chapitre Introduction a pour but de montrer, au travers des volutions technologiques des architectures et des contraintes du paralllisme, que le passage la paralllisation hybride est indispensable si lon veut tirer parti de la puissance des machines massivement parallles de dernire gnration. Or, un code hybride ne pourra tre performant que si les modes parallles MPI et OpenMP ont dj t optimiss. Cest lobjet des deux chapitres suivants MPI avanc et OpenMP avanc. Le chapitre Programmation hybride est entirement ddi lapproche hybride MPI+OpenMP. Les avantages lis la programmation hybride sont nombreux :

gains mmoire, meilleures performances, meilleur quilibrage de charge, granularit plus importante, do une extensibilit amliore, meilleure adquation du code aux spcicits matrielles de larchitecture cible.
Cependant, comme vous pourrez le constater dans les TPs, limplmentation sur une application relle ncessite un investissement important et une matrise approfondie de MPI et dOpenMP.
Introduction
16 septembre 2013
8 / 234
Loi de Moore
Enonc de la loi de Moore La loi de Moore dit que le nombre de transistors que lon peut mettre un cot raisonnable sur un circuit imprim double tous les 2 ans. Consommation lectrique Puissance lectrique dissipe = frequence3 (pour une technologie donne). Puissance dissipe par cm2 limite par le refroidissement. Cot de lnergie. Loi de Moore et consommation lectrique La frquence des processeurs naugmente plus en raison de la consommation lectrique prohibitive (frquence maximale bloque autour de 3 GHz depuis 2002-2004). Le nombre de transistors par puce continue doubler tous les 2 ans. => le nombre de curs par puce augmente (les Intel Ivy Bridge ont jusqu 12 curs et supportent 24 threads simultanment et les AMD Abu Dhabi 16 curs) => certaines architectures privilgient les curs basse frquence, mais en trs grand nombre (IBM Blue Gene)
Loi de Moore
CC BY-SA 3.0, http://en.wikipedia.org/wiki/Moore%27s_law P.-Fr. Lavalle P. Wautelet (IDRIS) Programmation hybride 16 septembre 2013 10 / 234
Le memory wall
Causes Les dbits vers la mmoire augmentent moins vite que la puissance de calcul des processeurs. Les latences (temps daccs) de la mmoire diminuent trs lentement. Le nombre de curs par barrette mmoire augmente. Consquences Lcart entre les performances thoriques des curs et la mmoire se creuse. Les processeurs passent de plus en plus de cycles attendre les donnes. Il est de plus en plus difcile dexploiter la performance des processeurs. Solutions partielles Lajout de mmoires caches est essentiel. Paralllisation des accs via plusieurs bancs mmoire comme sur les architectures vectorielles (Intel Sandy Bridge : 4 canaux et AMD Interlagos : 4). Si la frquence des curs stagne ou baisse, lcart pourrait se rduire.
Top 500
16 septembre 2013
12 / 234
Top 500
16 septembre 2013
13 / 234
Top 500
16 septembre 2013
14 / 234
Du ct des supercalculateurs
Evolution technique La puissance de calcul des supercalculateurs double tous les ans (plus rapide que la loi de Moore, mais la consommation lectrique augmente galement). Le nombre de curs augmente rapidement (architectures massivement parallles et many-cores). Apparition darchitectures hybrides (GPU, PowerXCell 8i ou FPGA et processeurs standards par exemple). Larchitecture des machines se complexie et le nombre de niveaux augmente (au niveau des processeurs/curs, accs la mmoire, rseau et I/O). La mmoire par cur stagne et commence dcrotre. La performance par cur stagne et est sur certaines machines beaucoup plus basse que sur un simple PC portable (IBM Blue Gene). Le dbit vers les disques augmente moins vite que la puissance de calcul.
16 septembre 2013
15 / 234
Loi dAmdahl
Enonc La loi dAmdahl prdit lacclration thorique maximale obtenue en paralllisant idalement un code, pour un problme donn et une taille de problme xe. Acc (P ) = Ts 1 1 = < ) T// (P ) + (1 P (P )
avec Acc le speedup, Ts la dure dexcution du code squentiel (monoprocesseur), T// (P ) la dure dexcution du code idalement paralllis sur P curs et la partie non paralllisable de lapplication.
Interprtation Quel que soit le nombre de curs, lacclration est toujours infrieure linverse du pourcentage que reprsente la partie purement squentielle. Exemple : si la partie purement squentielle dun code reprsente 20% de la dure du 1 code squentiel, alors quel que soit le nombre de curs, on aura : Acc < 20 =5 %
16 septembre 2013
16 / 234
Acclration thorique maximale Curs 10 100 1000 10000 100000 0 10 100 1000 10000 100000 0.01 9.99 99.0 909 5000 9091 10000 0.1 9.91 91.0 500 909 990 1000 1 9.17 50.2 91 99.0 99.9 100 (%) 2 8.47 33.6 47.7 49.8 49.9 50 5 6.90 16.8 19.6 19.96 19.99 20 10 5.26 9.17 9.91 9.99 10 10 25 3.08 3.88 3.99 3.99 4 4 50 1.82 1.98 1.998 2 2 2
16 septembre 2013
17 / 234
Loi de Gustafson-Barsis
Enonc La loi de Gustafson-Barsis prdit lacclration thorique maximale obtenue en paralllisant idalement un code, pour un problme de taille constante par cur et en supposant que la dure de la partie squentielle naugmente pas avec la taille globale du problme. Acc (P ) = P (P 1)
avec Acc le speedup, P le nombre de curs et la partie non paralllisable de lapplication.
Interprtation Cette loi est plus optimiste que celle dAmdahl car elle montre que lacclration thorique crot avec la taille du problme tudi.
16 septembre 2013
18 / 234
Consquences pour les utilisateurs
Consquences pour les applications Il faut exploiter un grand nombre de curs relativement lents. La mmoire par cur tend baisser, ncessit de la grer rigoureusement. Besoin dun niveau de paralllisme toujours plus important pour utiliser les architectures modernes (au point de vue puissance de calcul, mais aussi quantit de mmoire). Les entres-sorties deviennent galement un problme de plus en plus prsent. Consquences pour les dveloppeurs Fin de lpoque o il sufsait dattendre pour gagner en performance (stagnation de la puissance de calcul par cur). Besoins accrus de comprhension de larchitecture matrielle. De plus en plus compliqu de dvelopper dans son coin (besoin dexperts en HPC et dquipes multi-disciplinaires).
16 septembre 2013
19 / 234
Evolution des mthodes de programmation
Evolution des mthodes de programmation MPI est toujours prdominant et le restera encore un certain temps (communaut dutilisateurs trs importante et majorit des applications actuelles). Lhybride MPI-OpenMP se dveloppe et semble devenir lapproche privilgie pour les supercalculateurs. La programmation sur GPU se dveloppe, mais reste trs immature. Dautres formes de programmation hybride sont galement testes (MPI + GPU...) avec gnralement MPI comme ingrdient. De nouveaux langages de programmation parallle apparaissent (UPC, CoarrayFortran, langages PGAS, X10, Chapel...), mais ils sont en phase exprimentale ( des niveaux davancement trs variables). Certains de ces langages sont trs prometteurs. Il reste voir si ils vont tre utiliss dans de vraies applications.
16 septembre 2013
20 / 234
Conguration IDRIS
Turing : IBM Blue Gene/Q Ada : IBM x3750
16 septembre 2013
21 / 234
Conguration IDRIS
Chiffres importants Turing : 4 racks Blue Gene/Q :

4.096 nuds 65.536 curs 262.144 threads 64 Tio 839 Top/s 424 kW (106 kW/rack) 332 nuds de calcul et 4 nuds pour pr et post-traitement 10.624 curs Intel SandyBridge 2,7 GHz 46 Tio 230 Top/s 366 kW
Ada : 15 racks IBM x3750M4 :
2,2 Po utiles et 50 Gio/s sur disques partags entre BG/Q et Intel 790 kW pour la conguration complte (hors climatisation)
16 septembre 2013
22 / 234
Conguration IDRIS
16 septembre 2013
23 / 234
Architecture Blue Gene/Q
16 septembre 2013
24 / 234
MPI avanc
16 septembre 2013
25 / 234
Sommaire I
3
MPI avanc Introduction Historique Facteurs inuenant les performances MPI Communications MPI
Types de communications MPI Modes denvoi pour les communications point point Communications collectives Communications mmoire mmoire (RMA) Communications persistantes
Recouvrement calculs-communications Types drivs Equilibrage de charge Placement des processus
16 septembre 2013
26 / 234
Prsentation de MPI
Prsentation de MPI Paradigme de paralllisation pour architectures mmoire distribue bas sur lutilisation dune bibliothque portable. MPI est bas sur une approche de communications entre processus par passage de messages. MPI fournit diffrents types de communications :
Point point Collectives Copies mmoire mmoire
MPI fournit galement les fonctionnalits suivantes (non exhaustif) :

Environnement dexcution Types de donnes drivs Communicateurs et topologies Gestion dynamique de processus Entres-sorties parallles Interface de prolage
Programmation hybride 16 septembre 2013 27 / 234
Prsentation de MPI
Limitations de MPI Lacclration nale est limite par la partie purement squentielle du code (loi dAmdhal). Les surcots lis la bibliothque MPI et la gestion de lquilibrage de charge limitent lextensibilit. Certains types de communications collectives prennent de plus en plus de temps lorsque le nombre de processus augmente (par exemple MPI_Alltoall). Pas de distinction entre processus tournant en mmoire partage ou distribue. Or, limpact sur les performances des communications est majeur. La plupart des implmentations en tiennent compte, mais la norme ne permet pas de remontes dinformations vers lapplication. Peu de moyens disponibles dans la norme pour mettre en adquation le matriel et les processus MPI (placement des processus par exemple). Peut souvent se faire en dehors de la norme MPI.
16 septembre 2013
28 / 234
Historique
Pass Novembre 92 (Supercomputing 92) : formalisation dun groupe de travail cr en avril 92 et dcision dadopter les structures et les mthodes du groupe HPF (High Performance Fortran) Participants amricains (essentiellement) et europens (constructeurs et monde acadmique) Brouillon de MPI 1 prsent en novembre 93 (Supercomputing 93), nalis en mars 1994 Vise la fois la portabilit et la garantie de bonnes performances MPI 2 publi en juillet 97, suite des travaux ayant commenc au printemps 95 MPI 1.1 publi en 1995, 1.2 en 1997 et 1.3 en 2008, avec seulement des clarications et des changements mineurs (principalement dans quelques dnominations) Nouveaux groupes de travail constitus en novembre 2007 ( Supercomputing 07) pour travailler sur lvolution de MPI Trois nouvelles versions : 2.1, 2.2 et 3.0
16 septembre 2013
29 / 234
Historique
MPI 2.1 Uniquement pour des clarications mais aucun changement dans le standard 2.0. Fusion des versions 1.3 et 2.0. Publi en juin 2008. Voir http://www.mpi-forum.org/mpi2_1 http://meetings.mpi-forum.org/MPI_2.1_main_page.php. MPI 2.2 Corrections juges ncessaires au standard 2.1. Publi en septembre 2009. Voir http://meetings.mpi-forum.org/MPI_2.2_main_page.php.
16 septembre 2013
30 / 234
Historique
MPI 3.0 Changements et ajouts importants par rapport la version 2.2. Publi en septembre 2012. Principaux changements :

communications collectives non bloquantes ; rvision de limplmentation des copies mmoire mmoire ; Fortran (2003-2008) bindings ; suppression de linterface C++ ; interfaage doutils externes (pour le dbogage et les mesures de performance) ; etc.
voir http://meetings.mpi-forum.org/MPI_3.0_main_page.php https://svn.mpi-forum.org/trac/mpi-forum-web/wiki
16 septembre 2013
31 / 234
tat des implmentations actuelles
tat des implmentations actuelles Implmentation MPICH OpenMPI IBM Blue Gene/Q Intel MPI IBM PEMPI BullxMPI Cray Norme respecte norme 3.0 depuis version 3.0 (dcembre 2012) norme 2.1 (version 1.6.5, depuis 1.3.3) norme 2.2 (sans la gestion dynamique de processus ; bas sur MPICH2-1.5) norme 2.1 (version 4.0.3.8 ; bas sur MPICH2-4.0 update 3) norme 2.2 2.1 (version 1.1.16.5) norme 2.2
Remarque : la plupart des implmentations incluent une partie de la norme 3.0.
16 septembre 2013
32 / 234
Facteurs inuenant les performances MPI

Nuds de la machine Curs (frquence, nombre par nud...) Mmoire (dbits, latences, caches, nombre de canaux, partage entre les diffrents curs...) Cartes rseaux (dbits, latences, type, connexion au nud, nombre de liens...) Prsence ou non du moteur RDMA pour les communications OS (light kernel...) Conguration/tuning de la machine Rseau Type de carte (propritaire, InniBand, Ethernet...) Topologie rseau (en toile, tore 3D ou plus, fat tree, hypercube...) Protocole (bas niveau, TCP/IP...) Contention (entre processus du mme job ou entre diffrents jobs) Conguration/tuning du rseau
16 septembre 2013
33 / 234
Application Algorithmes, accs mmoire... Rapport calculs/communications, granularit Mthode de partage des donnes Equilibrage de charge Placement des processus Binding des processus sur les curs Entres/sorties Taille des messages Types de communications, utilisation de communicateurs...
16 septembre 2013
34 / 234
Implmentation MPI Adaptation larchitecture de la machine (implmentation constructeur, open source...) Utilisation des buffers Protocoles de communications (eager, rendez-vous...) Inuence des variables denvironnement Qualit de limplmentation et des algorithmes utiliss
16 septembre 2013
35 / 234
Types de communications MPI
Paradigmes de communications MPI MPI fournit plusieurs approches pour raliser des communications entre processus : Communications point point bloquantes ou non bloquantes Communications point point persistantes Communications collectives bloquantes Communications collectives non bloquantes partir de MPI 3.0 Copies mmoire mmoire (one sided communications, RMA)
16 septembre 2013
36 / 234
Modes denvoi point point
Modes denvoi point point Mode Envoi standard Envoi synchrone Envoi bufferis Envoi en mode ready Rception Bloquant MPI_Send MPI_Ssend MPI_Bsend MPI_Rsend MPI_Recv Non bloquant MPI_Isend MPI_Issend MPI_Ibsend MPI_Irsend MPI_Irecv
16 septembre 2013
37 / 234

Rappels terminologiques Il est important de bien comprendre la dnition de certains termes au sens MPI. Appel bloquant : un appel est bloquant si lespace mmoire servant la communication peut tre rutilis immdiatement aprs la sortie de lappel. Les donnes qui ont t ou seront envoyes sont celles qui taient dans cet espace au moment de lappel. Si il sagit dune rception, les donnes ont t reues dans cet espace (si le code de retour est MPI_SUCCESS). Appel non bloquant : un appel non bloquant rend la main trs rapidement, mais nautorise pas la rutilisation immdiate de lespace mmoire utilis dans la communication. Il est ncessaire de sassurer que la communication est bien termine (avec MPI_Wait par exemple) avant de lutiliser nouveau. Envoi synchrone : un envoi synchrone implique une synchronisation entre les processus concerns. Il ne peut donc y avoir communication que si les deux processus sont prts communiquer. Un envoi ne pourra commencer que lorsque sa rception sera poste. Envoi bufferis : un envoi bufferis implique la recopie des donnes dans un espace mmoire intermdiaire. Il ny a alors pas de couplage entre les deux processus de la communication. La sortie de ce type denvoi ne signie donc pas que la rception a eu lieu.
Envois synchrones
Envois synchrones Un envoi synchrone se fait en appelant le sous-programme MPI_Ssend ou MPI_Issend. Protocole de rendez-vous
Le protocole de rendez-vous est gnralement celui employ pour les envois en mode synchrone (dpend de limplmentation). Laccus de rception est optionnel.
16 septembre 2013
39 / 234
Envois synchrones
Avantages Consomment peu de ressources (pas de buffer) Rapides si le rcepteur est prt (pas de recopie dans un buffer) Garantie de la rception grce la synchronisation Inconvnients Temps dattente si le rcepteur nest pas l/pas prt Risques de deadlocks
16 septembre 2013
40 / 234
Envois bufferiss
Envois bufferiss Un envoi bufferis se fait en appellant le sous-programme MPI_Bsend ou MPI_Ibsend. Les buffers doivent tre grs manuellement (avec appels MPI_Buffer_attach et MPI_Buffer_detach). Ils doivent tre allous en tenant compte des surcots mmoire des messages (en ajoutant la constante MPI_BSEND_OVERHEAD pour chaque instance de message). Protocole avec buffer utilisateur du ct de lmetteur Cette approche est celle gnralement employe pour les appels MPI_Bsend ou MPI_Ibsend. Dans cette approche, le buffer se trouve du ct de lmetteur et est gre explicitement par lapplication. Un buffer gr par MPI peut exister du ct du rcepteur. De nombreuses variantes sont possibles. Laccus de rception est optionnel.
Envois bufferiss
Protocole eager Le protocole eager est souvent employ pour les envois en mode standard pour les messages de petites tailles. Il peut aussi tre utilis pour les envois avec MPI_Bsend avec des petits messages (dpend de limplmentation) et en court-circuitant le buffer utilisateur du ct de lmetteur. Dans cette approche, le buffer se trouve du ct du rcepteur. Laccus de rception est optionnel.
16 septembre 2013
42 / 234
Envois bufferiss
Avantages Pas besoin dattendre le rcepteur (recopie dans un buffer) Pas de risque de blocage (deadlocks) Inconvnients Consomment plus de ressources (occupation mmoire par les buffers avec risques de saturation) Les buffers denvoi utiliss dans les appels MPI_Bsend ou MPI_Ibsend doivent tre grs manuellement (souvent dlicat de choisir une taille adapte) Un peu plus lents que les envois synchrones si le rcepteur est prt Pas de garantie de la bonne rception (dcouplage envoi-rception) Risque de gaspillage despace mmoire si les buffers sont trop surdimensionns Lapplication plante si les buffers sont trop petits Il y a aussi souvent des buffers cachs grs par limplmentation MPI du ct de lexpditeur et/ou du rcepteur (et consommant des ressources mmoire)
16 septembre 2013
43 / 234
Envois standards
Envois standards Un envoi standard se fait en appelant le sous-programme MPI_Send ou MPI_Isend. Dans la plupart des implmentations, ce mode passe dun mode bufferis un mode synchrone lorsque la taille des messages crot. Avantages Souvent le plus performant (choix du mode le plus adapt par le constructeur) Le plus portable pour les performances Inconvnients Peu de contrle sur le mode rellement utilis (souvent accessible via des variables denvironnement) Risque de deadlock selon le mode rel Comportement pouvant varier selon larchitecture et la taille du problme
16 septembre 2013
44 / 234
Envois en mode ready
Envois en mode ready Un envoi en mode ready se fait en appellant le sous-programme MPI_Rsend ou MPI_Irsend. Attention : il est obligatoire de faire ces appels seulement lorsque la rception est dj poste. Leur utilisation est fortement dconseille. Avantages Lgrement plus performant que le mode synchrone car le protocole de synchronisation peut tre simpli Inconvnients Erreurs si le rcepteur nest pas prt lors de lenvoi
16 septembre 2013
45 / 234
16 septembre 2013
46 / 234
16 septembre 2013
47 / 234
16 septembre 2013
48 / 234
Communications collectives
Dnitions et caractristiques gnrales Les communications collectives permettent de raliser des communications impliquant plusieurs processus. Elles peuvent toujours tre simules par un ensemble de communications point point (mais peuvent tre fortement optimises) avec ventuellement des oprations de rduction. Une communication collective implique lensemble des processus du communicateur utilis. Jusqu MPI 2.2, il sagissait dappels bloquants (cd quun processus ne sort de lappel que lorsque sa participation la communication est termine). La norme MPI 3.0 introduit les appels non bloquants pour les communications collectives. Les communications collectives nimpliquent pas de synchronisation globale (sauf MPI_Barrier) et nen ncessitent pas. Elles ninterfrent jamais avec les communications point point. Il faut toujours (ou presque) les prfrer aux communications point point.
16 septembre 2013
49 / 234
Catgories Les communications collectives peuvent tre spares en 3 catgories : Synchronisations globales (MPI_Barrier) nutiliser que si ncessaire (rare) Tranferts/changes de donnes
Diffusion de donnes (globales avec MPI_Bcast, slectives avec MPI_Scatter) Collecte de donnes (MPI_Gather et MPI_Allgather) Echanges globaux (MPI_Alltoall)
Oprations de rduction (MPI_Reduce, MPI_Allreduce, MPI_Reduce_scatter et MPI_Scan)
16 septembre 2013
50 / 234
Avantages (par rapport au point point) Sont fortement optimises. Une srie de communications point point en une seule opration. Inconvnients (par rapport au point point) Peut cacher au programmeur un volume de transfert trs important (par exemple, un MPI_Alltoall avec 1024 processus implique plus de 1 million de messages point point). Pas dappels non bloquants (plus vrai dans la norme MPI 3.0). Implique tous les processus du communicateur. Il faut donc crer des sous-communicateurs si tous les processus ne sont pas concerns par une communication collective.
16 septembre 2013
51 / 234
Collectif vs point point
Diffusion globale simule avec des communications point point (boucle de MPI_Send sur un processus et MPI_Recv sur les autres) versus un appel MPI_Bcast
Dnition synchronisation globale Une synchronisation globale (ou barrire) est une opration telle qu un instant donn lensemble des processus concerns seront dans un mme appel. Un processus arrivant dans cet appel ne pourra pas en sortir tant que tous les autres ny sont pas. Par contre, rien nimpose quils en sortent tous simultanment. Communications collectives synchronisantes ? Les communications collectives nimpliquent pas de synchronisation globale (sauf MPI_Barrier) et nen ncessitent pas. Les implmentations sont libres den mettre dans tous les appels collectifs et les dveloppeurs doivent sassurer que leurs applications fonctionnent dans ces cas.
16 septembre 2013
53 / 234
Communications mmoire mmoire (RMA)
Dnition
Les communications mmoire mmoire (ou RMA pour Remote Memory Access ou one sided communications) consistent accder en criture ou en lecture la mmoire dun processus distant sans que ce dernier doive grer cet accs explicitement. Le processus cible nintervient donc pas lors du transfert.
16 septembre 2013
54 / 234

Approche gnrale Cration dune fentre mmoire avec MPI_Win_create pour autoriser les transferts RMA dans cette zone. Accs distants en lecture ou criture en appellant MPI_Put, MPI_Get ou MPI_Accumulate. Libration de la fentre mmoire avec MPI_Win_free. Mthodes de synchronisation Pour sassurer dun fonctionnement correct, il est obligatoire de raliser certaines synchronisations. 3 mthodes sont disponibles : Communication cible active avec synchronisation globale (MPI_Win_fence) ; Communication cible active avec synchronisation par paire (MPI_Win_Start et MPI_Win_Complete pour le processus origine ; MPI_Win_Post et MPI_Win_Wait pour le processus cible) ; Communication cible passive sans intervention de la cible (MPI_Win_lock et MPI_Win_unlock).
16 septembre 2013
55 / 234
Avantages Permet de mettre en place plus efcacement certains algorithmes. Plus performant que les communications point point sur certaines machines (utilisation de matriels spcialiss tels que moteur DMA, coprocesseur, mmoire spcialise...). Possibilit pour limplmentation de regrouper plusieurs oprations. Inconvnients La gestion des synchronisations est dlicate. Complexit et risques derreurs levs. Pour les synchronisations cible passive, obligation dallouer la mmoire avec MPI_Alloc_mem qui ne respecte pas la norme Fortran (utilisation de pointeurs Cray non supports par certains compilateurs). Moins performant que les communications point point sur certaines machines.
16 septembre 2013
56 / 234
16 septembre 2013
57 / 234
16 septembre 2013
58 / 234
Communications persistantes
Caractristiques Les communications persistantes permettent de rpter volont des communications portant sur le mme espace mmoire, mais avec des valeurs diffrentes. Lavantage est dviter dinitialiser ces communications (et les structures de donnes associes) chaque appel (thoriquement moins de surcots). Un canal de communication est ainsi cr pour lenvoi des messages. Ce sont des communications point point non bloquantes. Les communications MPI persistantes napportent aucun gain signicatif sur les machines actuelles. Les performances sont gnralement trs proches de celles des communications point point standards non bloquantes. Lutilisation des communications persistantes nest pas conseille car elles napportent (actuellement) aucun avantage.
16 septembre 2013
59 / 234
Utilisation Initialisation de la communication persistante avec MPI_Send_init/MPI_Recv_init (ou variantes) Rptition de la squence de communication (dans une boucle par exemple) :
Dbut de la communication avec appel MPI_Start Fin de la communication (non bloquante) avec MPI_Wait
Libration des ressources avec MPI_Request_free Exemple call MPI_Send_init(data,sz,MPI_REAL,dest,tag,comm,req,ierr) do i=1,niter call MPI_Start(req,ierr) call kernel() call MPI_Wait(req,MPI_STATUS_IGNORE,ierr) end do call MPI_Request_free(req,ierr)
16 septembre 2013
60 / 234
16 septembre 2013
61 / 234
Recouvrement calculs-communications
Prsentation Le recouvrement des communications par des calculs est une mthode permettant de raliser des oprations de communications en arrire-plan pendant que le programme continue de sexcuter. Il est ainsi possible, si larchitecture matrielle et logicielle le permet, de masquer tout ou partie des cots de communications. Le recouvrement calculs-communications peut tre vu comme un niveau supplmentaire de paralllisme. Cette approche sutilise dans MPI par lutilisation de sous-programmes non-bloquants (i.e. MPI_Isend, MPI_Irecv et MPI_Wait).
16 septembre 2013
62 / 234
16 septembre 2013
63 / 234
Avantages Possibilit de masquer tout ou partie des cots des communications (si larchitecture le permet) Pas de risques de deadlock Inconvnients Surcots plus importants (plusieurs appels pour un seul envoi ou rception, gestion des requtes) Complexit plus leve et maintenance plus complique Peu performant sur certaines machines (par exemple avec transfert commenant seulement lappel de MPI_Wait) Risque de perte de performance sur les noyaux de calcul (par exemple gestion diffrencie entre la zone proche de la frontire dun domaine et la zone intrieure entranant une moins bonne utilisation des caches mmoire) Limit aux communications point point (a t tendu aux collectives dans MPI 3.0)
16 septembre 2013
64 / 234
Utilisation Lenvoi dun message se fait en 2 tapes : Initier lenvoi ou la rception par un appel un sous-programme commenant par MPI_Isend ou MPI_Irecv (ou une de leurs variantes) Attendre la n de la contribution locale par un appel MPI_Wait (ou une de ses variantes). Les communications se recouvrent par toutes les oprations qui se droulent entre ces deux tapes. Laccs aux donnes en cours de rception est interdit avant la n de lappel MPI_Wait (laccs aux donnes en cours denvoi est galement interdit pour les implmentations MPI antrieures la 2.2).
16 septembre 2013
65 / 234
Exemple do i=1,niter ! Initie les communications call MPI_Irecv(data_ext, sz,MPI_REAL,dest,tag,comm, & req(1),ierr) call MPI_Isend(data_bound,sz,MPI_REAL,dest,tag,comm, & req(2),ierr) ! Calcule le domaine interieur (data_ext et data_bound ! non utilises) pendant que les communications ont lieu call calcul_domaine_interieur(data_int) ! Attend la fin des communications call MPI_Waitall(2,req,MPI_STATUSES_IGNORE,ierr) ! Calcule le domaine exterieur call calcul_domaine_exterieur(data_int,data_bound,data_ext) end do
16 septembre 2013
66 / 234
Niveau de recouvrement sur diffrentes machines Machine Blue Gene/Q, PAMID_THREAD_MULTIPLE=0 Blue Gene/Q, PAMID_THREAD_MULTIPLE=1 Ada, dfaut Ada MP_USE_BULK_XFER=yes NEC SX-8 CURIE Niveau 32% 100% 0% 100% en extranud 0% en intranud 10% 0%
Mesures faites en recouvrant un noyau de calcul et un noyau de communication de mmes dures et en utilisant diffrents schmas de communications (intra/extra-nuds, par paires, processus alatoires...). Selon le schma de communication, les rsultats peuvent tre totalement diffrents. Un recouvrement de 0% signie que la dure totale dexcution vaut 2x la dure dun noyau de calcul (ou communication). Un recouvrement de 100% signie que la dure totale vaut 1x la dure dun noyau de calcul (ou communication).
16 septembre 2013
67 / 234
Types drivs
Prsentation Les types drivs permettent de reprsenter des structures de donnes de nimporte quelle complexit. Un niveau dabstraction important peut tre ainsi atteint et permet de cacher la complexit sous-jacente. Peuvent tre utiliss dans toutes les communications MPI, mais galement dans les entres-sorties.
16 septembre 2013
68 / 234
Types drivs existants
Types drivs existants Type Types prdnis MPI_Type_contiguous MPI_Type_vector MPI_Type_indexed MPI_Type_struct Donnes multiples Non contigu Espacement quelconque Htrogne

MPI_Type_vector et MPI_Type_indexed donnent les carts en multiples entiers du type de base. Les variantes MPI_Type_create_hvector et MPI_Type_create_hindexed permettent de fournir des carts en octets. Il existe galement deux autres types drivs : MPI_Type_create_subarray pour crer des sous-tableaux et MPI_Type_create_darray pour des tableaux distribus sur un ensemble de processus.
16 septembre 2013
69 / 234
Types drivs : avantages
Avantages Lisibilit Niveau dabstraction lev Types non-contigus supports Types htrognes supports Regroupement de messages Utilisables aussi dans les I/O
16 septembre 2013
70 / 234
Types drivs : inconvnients
Inconvnients Peuvent tre complexes mettre en place Types htrognes dlicats mettre en uvre Niveau dabstraction lev perte de matrise Performances souvent moindres
16 septembre 2013
71 / 234
Types drivs : alternatives
Copies manuelles dans structures intermdiaires Gestion des donnes la main avec copie dans des structures intermdiaires Souvent le plus performant Implique des copies mmoire mmoire supplmentaires Utilisation de plus de ressources mmoire Gestion manuelle de lespace mmoire Nutilise pas les possibilits de certains sous-systmes de communications (scatter-gather hardware) ou systmes de chiers parallles spcialiss (PVFS par exemple) Messages spars Envoi des donnes dans des messages spars. Attention : si nombreux messages, trs mauvaises performances. A viter absolument.
16 septembre 2013
72 / 234
Types drivs : alternatives
MPI_Pack/MPI_Unpack Utilisation des sous-programmes MPI_Pack/MPI_Unpack Souvent peu performant Mmes dfauts que la gestion manuelle avec copie dans des structures intermdiaires Possibilit de recevoir un message en plusieurs fois ou de le prparer en plusieurs fois Peut tre utilis avec des types drivs
16 septembre 2013
73 / 234
16 septembre 2013
74 / 234
16 septembre 2013
75 / 234
16 septembre 2013
76 / 234
Equilibrage de charge
Dnitions Une application parallle MPI a un quilibre de charge parfait lorsque tous les processus prennent le mme temps entre deux synchronisations (explicites ou non). Une quantit de travail diffrente entre les processus entrane un dsquilibre de charge avec des temps dattente pour les plus rapides, des dsynchronisations et une extensibilit moindre. Le processus le plus lent est dimensionnant.
Une autre forme de dsquilibre est le dsquilibre de mmoire entre processus. Cela peut devenir problmatique sur les machines ayant peu de mmoire par nud.
16 septembre 2013
77 / 234
Equilibrage de charge
Quelques causes de dsquilibre Mauvais partage des donnes ds la conception Adaptation dynamique de maillage (AMR) Processus itratifs avec nombre ditrations diffrent selon les variables, mailles... Sources externes lapplication : OS jitter, ressources non ddies... Quelques pistes pour (r)quilibrer Rquilibrage dynamique en cours dexcution avec changes de mailles entre les processus (utilisation de la courbe de remplissage spatial de Hilbert...) Approche matre(s)-esclaves Utilisation de bibliothques de partitionnement (PT-SCOTCH, ParMETIS...) Plusieurs sous-domaines par processus Approche hybride MPI-OpenMP
16 septembre 2013
78 / 234
Placement des processus
Dnitions Chaque processus MPI a un rang dans le communicateur MPI_COMM_WORLD (allant de 0 Nprocessus-1). Chaque processus MPI est plac de faon statique sur un nud de la machine (pas de migrations entre nuds en cours dexcution). Sur de nombreuses machines de calcul, chaque processus est galement plac de faon statique sur un cur donn (procd appell binding ou afnit) (pas de migrations entre curs en cours dexcution). Le placement (ou mapping) correspond la relation entre le rang du processus et sa position sur la machine.
16 septembre 2013
79 / 234
Importance Plus le nombre de processus est lev, plus il y a de communications et plus la distance moyenne (le nombre de liens/bus mmoires et rseaux traverser) entre chaque processus augmente. La latence augmente avec la distance. La contention du rseau ou de la mmoire augmente si des messages traversent plusieurs liens. Limpact dun mauvais placement peut tre trs lv. Lidal est de ne communiquer quentre voisins proches.
16 septembre 2013
80 / 234
Adaptation logiciel Utiliser MPI_Dims_create et MPI_Cart_create et laisser le plus de libert possible MPI (ne pas imposer de dimensions et autoriser la renumrotation des processus). Connatre son application et ses modes/patterns de communications. Communiquer avec ses voisins les plus proches. Dcouper ses maillages pour coller au mieux la machine. Outils de placement numactl permet de choisir lafnit sur de nombreux systmes Linux. La bibliothque hwloc donne accs de nombreuses informations sur la topologie des nuds dune machine et peut contrler le binding. Sur Blue Gene/Q, le placement des processus se fait en utilisant loption --mapping de runjob.
16 septembre 2013
81 / 234
Exemple : topologie de la Blue Gene/P

Topologie de la Blue Gene/P
Pour les communications point--point et certaines collectives, la topologie rseau est un tore 3D. Chaque nud de calcul est connect ses 6 voisins par des liens rseaux bidirectionnels. Lidal est de ne communiquer quavec ses voisins directs.
Topologies cartsiennes Les topologies cartsiennes 3D et 4D peuvent tre places de faon optimale par MPI sur le tore 3D (4D si en mode DUAL ou VN).
16 septembre 2013
82 / 234
Exemple dextensibilit sur Blue Gene/P
16 septembre 2013
83 / 234
OpenMP avanc
16 septembre 2013
84 / 234
Sommaire I
4
OpenMP avanc Introduction Limitations dOpenMP Approche classique Fine-grain (FG) Approche Coarse-grain (CG) CG vs. FG : surcots du partage du travail CG Impact au niveau du code source CG Synchronisations nes Performances compares MPI/OpenMP-FG/OpenMP-CG Conclusion
16 septembre 2013
85 / 234
OpenMP en deux mots...
Prsentation dOpenMP Paradigme de paralllisation pour architecture mmoire partage bas sur des directives insrer dans le code source (C, C++, Fortran). OpenMP est constitu dun jeu de directives, dune bibliothque de fonctions et dun ensemble de variables denvironnement. OpenMP fait partie intgrante de tout compilateur Fortran/C/C++ rcent. Il permet de grer :

la cration des processus lgers, le partage du travail entre ces processus lgers, les synchronisations (explicites ou implicites) entre tous les processus lgers, le statut des variables (prives ou partages).
16 septembre 2013
86 / 234
OpenMP en deux mots...

Schma de principe
16 septembre 2013
87 / 234
Limitations dOpenMP
Limitations dOpenMP (1) Lextensibilit du code parallle est physiquement limite par la taille du nud mmoire partage sur lequel il sexcute. En pratique, la bande passante mmoire cumule lintrieur dun nud SMP peut encore plus limiter le nombre de curs utilisables efcacement. Les contentions dues la limitation de la bande passante mmoire peuvent souvent tre leves en optimisant lutilisation des caches. Attention aux surcots implicites dOpenMP lors de la cration des processus lgers, de la synchronisation entre les processus lgers (implicite ou explicite) ou du partage du travail comme le traitement des boucles parallles par exemple. Dautres surcots directement lis larchitecture de la machine cible peuvent aussi inuer sur les performances, comme le false sharing sur des caches partags ou laspect NUMA des accs mmoire. Le binding des processus lgers sur les curs physiques de la machine sont la charge du systme (accessible au dveloppeur en utilisant certaines bibliothques). Son impact sur les performances peut tre trs important.
16 septembre 2013
88 / 234
Limitations dOpenMP
Limitations dOpenMP (2) OpenMP ne gre pas laspect localisation des donnes, ce qui pose un vrai problme sur architecture fortement NUMA et interdit toute utilisation sur architecture base de GPGPU. OpenMP nest pas adapt des problmatiques dynamiques (i.e. dont la charge de travail volue rapidement au cours de lexcution). Comme pour nimporte quelle paralllisation de code, lacclration nale sera limite par la partie purement squentielle du code (loi dAmdahl).
16 septembre 2013
89 / 234
Lapproche classique Fine-grain (FG)
Dnition OpenMP grain n ou Fine-grain (FG) : utilisation des directives OpenMP pour partager le travail entre les threads, en particulier au niveau des boucles parallles avec la directive DO. Avantages Simplicit de mise en oeuvre ; la paralllisation ne dnature pas le code ; une seule version du code grer pour la version squentielle et parallle. Une approche incrmentale de la paralllisation du code est possible. Si on utilise les directives OpenMP de partage du travail (WORKSHARE, DO, SECTION), alors des synchronisations implicites gres par OpenMP simplient grandement la programmation (i.e. boucle parallle avec rduction). Sur les boucles parallles, un quilibrage dynamique de charge peut tre ralis via les options de la clause SCHEDULE (DYNAMIC, GUIDED).
16 septembre 2013
90 / 234
Lapproche classique Fine-grain (FG)
Inconvnients Les surcots dus au partage du travail et la cration/gestion des threads peuvent se rvler importants, particulirement lorsque la granularit du code parallle est petite/faible. Certains algorithmes ou nids de boucles peuvent ne pas tre directement paralllisables car ils requirent des synchronisations plus nes que de simples barrires, exclusions mutuelles ou excution single. Dans la pratique, on observe une extensibilit limite des codes (en tout cas infrieure celle du mme code paralllis avec MPI), mme lorsquils sont bien optimiss. Plus la granularit du code est ne, plus ce phnomme saccentue.
16 septembre 2013
91 / 234
Lapproche Coarse-grain (CG)
Dnition OpenMP gros grain SPMD ou Coarse-grain (CG) : encapsulation du code dans une seule rgion parallle et distribution du travail sur les threads la main. Avantages Pour des codes petite granularit, les surcots de partage du travail sont bien plus faibles quavec lapproche Fine-grain. Trs bonne extensibilit lorsque le code sy prte (comparable et mme le plus souvent meilleure que celle obtenue en paralllisant le code avec MPI). On verra dans la suite que cest lapproche qui donne les meilleures performances sur un nud SMP.
16 septembre 2013
92 / 234
Lapproche Coarse-grain (CG)
Inconvnients Approche trs intrusive dans le code. Il nest plus possible davoir une seule et unique version du code grer. Lapproche incrmentale de paralllisation du code nest plus possible. Les synchronisations (globales ou au niveau des threads) sont ENTIREMENT la charge du programmeur. Le partage du travail et lquilibrage de charge est aussi de la responsabilit du programmeur. Au nal, la mise en uvre se rvle au moins aussi complexe quune paralllisation avec MPI.
16 septembre 2013
93 / 234
OpenMP Coarse-grain : le partage du travail

Exemple dune boucle parallle Considrons la simple boucle parallle ci-dessous rpte nbIter = 106 fois. do iter=1,nbIter do i=1,n B(i) = B(i) * a + iter enddo enddo La paralllisation Fine-grain de la boucle interne est trs simple : la rpartition du travail se fait en utilisant la directive OpenMP DO. Via la clause SCHEDULE(RUNTIME), le mode de rpartition du traitement des blocs ditrations par les threads se fera lexcution. Un quilibrage dynamique de charge peut se faire avec les modes DYNAMIC ou GUIDED, mais attention aux surcots potentiels lexcution ! do iter=1,nbIter !$OMP DO SCHEDULE(RUNTIME) do i=1,n B(i) = B(i) * a + iter enddo enddo
Exemple dune boucle parallle Paralllisation Coarse-grain version 1 avec quilibrage de charge statique, chaque thread traitant des itrations non conscutives : !$ myOMPRank = OMP_GET_THREAD_NUM() !$ nbOMPThreads = OMP_GET_NUM_THREADS() do iter=1,nbIter do i=1+myOMPRank,n,nbOMPThreads B(i) = B(i) * a + iter enddo enddo Cela revient en fait une boucle parallle dont la rpartition est de type STATIC avec une taille de bloc gale 1 (i.e. une seule itration).
16 septembre 2013
95 / 234
Exemple dune boucle parallle (suite) Paralllisation Coarse-grain version 2 sans quilibrage de charge, chaque thread traitant un bloc ditrations conscutives : !$ myOMPRank = OMP_GET_THREAD_NUM() !$ nbOMPThreads = OMP_GET_NUM_THREADS() nbnLoc = n/nbOMPThreads iDeb = 1+myOMPRank*nbnLoc iFin = iDeb+nbnLoc-1 if (myOMPRank==nbOMPThreads-1) iFin = n do iter=1,nbIter do i=iDeb,iFin B(i) = B(i) * a + iter enddo enddo
16 septembre 2013
96 / 234
Exemple dune boucle parallle (suite) Paralllisation Coarse-grain version 3 avec quilibrage de charge statique, chaque thread traitant un bloc ditrations conscutives : !$ myOMPRank = OMP_GET_THREAD_NUM() !$ nbOMPThreads = OMP_GET_NUM_THREADS() iDeb = 1+(myOMPRank*n)/nbOMPThreads iFin = ((myOMPRank+1)*n)/nbOMPThreads do iter=1,nbIter do i=iDeb,iFin B(i) = B(i) * a + iter enddo enddo
16 septembre 2013
97 / 234
Coarse-grain versus Fine-grain

Coarse-grain versus Fine-grain : surcots dus au partage du travail
FG CG V1 CG V2 CG V3 Mono 2.75 2.75 2.75 2.75 1 core 2.65 6.04 6.19 6.19 2 cores 5.44 13.84 3.10 3.09 4 cores 7.26 17.06 1.54 1.54 8 cores 14.75 21.53 0.79 0.77 16 cores 65.97 46.96 0.40 0.39 24 cores 187.2 57.0 0.29 0.27 32 cores 458.4 58.7 0.26 0.19
Conclusions La boucle parallle version Fine-grain donne des rsultats catastrophiques, les surcots tant si importants que les temps de restitution explosent avec le nombre de threads. Les rsultats sont encore pire si on utilise le mode DYNAMIC de rpartition des itrations sur les threads puisque, par dfaut, si on ne spcie pas de taille de bloc, il cre autant de blocs que ditrations ! Les deux seules versions qui sont extensibles sont les versions CG V2 et V3, limpact de lquilibrage de charge napparaissant quau del de 24 threads. Les performances, rapportes la granularit de la boucle paralllise, sont excellentes (acclration de 14,5 sur 32 threads). Lapproche Coarse-grain limite limpact des surcots ce qui permet une extensibilit optimale du code paralllis.
Approche Coarse-grain
Approche Coarse-grain : impact au niveau du code source Contrairement lapproche Fine-grain qui est trs peu intrusive dans le code source (uniquement des ajouts de directives OpenMP), lapproche Coarse-grain requiert beaucoup de rcriture de code, la ncssit dintroduire de nouvelles variables, etc. Un exemple classique simple : comment parallliser une boucle avec une rduction dans une version Coarse-grain ? On ne peut plus utiliser la clause REDUCTION de la directive DO. Il va falloir lmuler la main... Chaque thread va calculer une rduction locale dans une variable prive, puis va accumuler les rductions locales dans une mme variable partage, mais un seul thread la fois ! Pour la version FG, une seule directive OpenMP (2 lignes modies ou ajoutes) est utilise. Pour la version CG, il faut introduire ou modier pas moins de 14 lignes de code et utiliser 4 directives ou appels de fonction de la bibliothque OpenMP ! ! !
16 septembre 2013
99 / 234
Calcul de
Exemple du calcul de , version squentielle

program pi ! __ ! But : calcul de || par la methode des rectangles (point milieu). ! ! / 1 ! | 4 __ ! | ---------- dx = || ! | 1 + x**2 ! / 0 implicit none integer, parameter :: n=30000000 real(kind=8) :: f, x, a, h, Pi_calcule integer :: i ! Fonction instruction a integrer f(a) = 4.0_8 / ( 1.0_8 + a*a ) ! Longueur de lintervalle dintegration. h = 1.0_8 / real(n,kind=8) ! Calcul de Pi Pi_calcule = 0.0_8 do i = 1, n x = h * ( real(i,kind=8) - 0.5_8 ) Pi_calcule = Pi_calcule + f(x) end do Pi_calcule = h * Pi_calcule end program pi
16 septembre 2013
100 / 234
Calcul de
Exemple du calcul de , version parallle OpenMP Fine-grain
program pi ! __ ! But : calcul de || par la methode des rectangles (point milieu). ! ! / 1 ! | 4 __ ! | ---------- dx = || ! | 1 + x**2 ! / 0 implicit none integer, parameter :: n=30000000 real(kind=8) :: f, x, a, h, Pi_calcule integer :: i ! Fonction instruction a integrer f(a) = 4.0_8 / ( 1.0_8 + a*a ) ! Longueur de lintervalle dintegration. h = 1.0_8 / real(n,kind=8) ! Calcul de Pi Pi_calcule = 0.0_8 !$OMP PARALLEL DO PRIVATE(x) REDUCTION(+:Pi_calcule) do i = 1, n x = h * ( real(i,kind=8) - 0.5_8 ) Pi_calcule = Pi_calcule + f(x) end do !$OMP END PARALLEL DO Pi_calcule = h * Pi_calcule end program pi
16 septembre 2013
101 / 234
Calcul de
Exemple du calcul de , version parallle OpenMP Coarse-grain
program pi !$ use OMP_LIB implicit none integer, parameter :: n=30000000 real(kind=8) :: f, x, a, h, Pi_calcule, Pi_calcule_loc integer :: i, iDeb, iFin, myOMPRank, nbOMPThreads ! Fonction instruction a integrer f(a) = 4.0_8 / ( 1.0_8 + a*a ) ! Initialisation de myOMPRank et nbOMPThreads myOMPRank=0 nbOMPThreads=1 ! Longueur de lintervalle dintegration. h = 1.0_8 / real(n,kind=8) ! Calcul de Pi Pi_calcule = 0.0_8 Pi_calcule_loc = 0.0_8 !$OMP PARALLEL PRIVATE(x,myOMPRank) FIRSTPRIVATE(Pi_calcule_loc) !$ myOMPRank = OMP_GET_THREAD_NUM() !$ nbOMPThreads = OMP_GET_NUM_THREADS() iDeb = 1+(myOMPRank*n)/nbOMPThreads iFin = ((myOMPRank+1)*n)/nbOMPThreads do i = iDeb, iFin x = h * ( real(i,kind=8) - 0.5_8 ) Pi_calcule_loc = Pi_calcule_loc + f(x) end do !$OMP ATOMIC Pi_calcule = Pi_calcule + Pi_calcule_loc !$OMP END PARALLEL Pi_calcule = h * Pi_calcule end program pi
16 septembre 2013
102 / 234
Synchronisations nes
Synchronisation ne entre deux ou plusieurs threads Les synchronisations fournies par OpenMP (BARRIER, SINGLE, ATOMIC, etc) ne sont pas adaptes la paralllisation de type Coarse-grain qui requirent des synchronisations plus bas niveau. Hlas, rien nest disponible cet effet dans OpenMP. Il va donc revenir au programmeur dmuler ces fonctionnalits en utilisant les variables partages et la directive FLUSH pour changer de linformation entre deux ou plusieurs autres threads. Certains algorithmes ne sont pas paralllisables sans avoir recours ce type de synchronisation. Cest lourd coder, source derreurs et cela dnature le code, mais cest indispensable...
16 septembre 2013
103 / 234
CG Synchronisations nes
La directive OpenMP FLUSH Rappel : la directive OpenMP FLUSH permet de remettre jour toute la hirarchie mmoire dun thread associe aux variables partages listes en argument. Si il ny a pas dargument la commande FLUSH, toutes les variables partages visibles par le thread sont mises jour (extrmement coteux !). Plus prcisment, sur le thread qui fait lappel au FLUSH :
les variables partages listes en argument et ayant t mises jour depuis le dernier
FLUSH voient leur valeur recopie en mmoire partage,

les variables partages listes en argument et nayant pas t mises jour depuis le
dernier FLUSH voient leur ligne de cache invalide. Ainsi, toute nouvelle rfrence cette variable correspondra une lecture en mmoire partage de la valeur de la variable.
Supposons quun algorithme compos de plusieurs parties (T1 , T2 , . . . , Tn ) possde les dpendances suivantes : i = 1, . . . , n1 Ti +1 ne peut commencer sexcuter que lorsque Ti est termin
La synchronisation ne entre deux threads ncessaire pour grer ces dpendances peut simplmenter comme dans le code suivant :
16 septembre 2013
104 / 234
Gestion des dpendances
Exemple de dpendances gres la main

program anneau1 !$ use OMP_LIB implicit none integer :: rang,nb_taches,synch=0 !$OMP PARALLEL PRIVATE(rang,nb_taches) rang=OMP_GET_THREAD_NUM() nb_taches=OMP_GET_NUM_THREADS() do !$OMP FLUSH(synch) if(synch==mod(rang-1+nb_taches,nb_taches)) & exit end do print *,"Rang:",rang,";synch:",synch synch=rang !$OMP FLUSH(synch) !$OMP END PARALLEL end program anneau1
16 septembre 2013
105 / 234
Exemple pige facile

program anneau2-faux !$ use OMP_LIB integer :: rang,nb_taches,synch=0,compteur=0 !$OMP PARALLEL PRIVATE(rang,nb_taches) rang=OMP_GET_THREAD_NUM() nb_taches=OMP_GET_NUM_THREADS() if (rang == 0) then ; do !$OMP FLUSH(synch) if(synch == nb_taches-1) exit end do else ; do !$OMP FLUSH(synch) if(synch == rang-1) exit end do end if compteur=compteur+1 print *,"Rang:",rang,";synch:",synch,";compteur:",compteur synch=rang !$OMP FLUSH(synch) !$OMP END PARALLEL print *,"Compteur = ",compteur end program anneau2-faux
16 septembre 2013
106 / 234
Exemple pige difcile et vicieux

program anneau3-faux !$ use OMP_LIB integer :: rang,nb_taches,synch=0,compteur=0 !$OMP PARALLEL PRIVATE(rang,nb_taches) rang=OMP_GET_THREAD_NUM(); nb_taches=OMP_GET_NUM_THREADS() if (rang == 0) then ; do !$OMP FLUSH(synch) if(synch == nb_taches-1) exit end do else ; do !$OMP FLUSH(synch) if(synch == rang-1) exit end do end if print *,"Rang:",rang,";synch:",synch," !$OMP FLUSH(compteur) compteur=compteur+1 !$OMP FLUSH(compteur) synch=rang !$OMP FLUSH(synch) !$OMP END PARALLEL print *,"Compteur = ",compteur end program anneau3-faux
16 septembre 2013
107 / 234
Synchronisations nes
Commentaires sur les codes prcdents Dans anneau2-faux, on na pas ush la variable partage compteur avant et aprs lavoir incrmente. Le rsultat nal peut potentiellement tre faux. Dans anneau3-faux, le compilateur peut inverser les lignes : compteur=compteur+1 !$OMP FLUSH(compteur) et les lignes : synch=rang !$OMP FLUSH(synch) librant le thread qui suit avant que la variable compteur nait t incrmente... L encore, le rsultat nal pourrait potentiellement tre faux. Pour rsoudre ce problme, il faut usher les deux variables compteur et synch juste aprs lincrmentation de la variable compteur, ainsi on impose un ordre au compilateur. Le code corrig se trouve ci-dessous...
16 septembre 2013
108 / 234

Le code corrig...
program anneau4 !$ use OMP_LIB integer :: rang,nb_taches,synch=0,compteur=0 !$OMP PARALLEL PRIVATE(rang,nb_taches) rang=OMP_GET_THREAD_NUM() nb_taches=OMP_GET_NUM_THREADS() if (rang == 0) then ; do !$OMP FLUSH(synch) if(synch == nb_taches-1) exit end do else ; do !$OMP FLUSH(synch) if(synch == rang-1) exit end do end if print *,"Rang:",rang,";synch:",synch," !$OMP FLUSH(compteur) compteur=compteur+1 !$OMP FLUSH(compteur,synch) synch=rang !$OMP FLUSH(synch) !$OMP END PARALLEL print *,"Compteur = ",compteur end program anneau4
16 septembre 2013
109 / 234
Nid de boucles avec double dpendance

Description et analyse du problme Considrons le code suivant :
! Boucles avec double dependance do j = 2, ny do i = 2, nx V(i,j) =(V(i,j) + V(i-1,j) + V(i,j-1))/3 end do end do
Cest un problme classique en paralllisme qui se retrouve par exemple dans les NAS Parallel Benchmarks (application LU). Du fait de la dpendance arrire en i et en j, ni la boucle en i, ni la boucle en j ne sont parallles (i.e. chaque itration en i ou j dpend de litration prcdente). Parallliser avec la directive OpenMP PARALLEL DO la boucle en i ou la boucle en j donnerait des rsultats faux. Pourtant, il est quand mme possible dexhiber du paralllisme de ce nid de boucles en effectuant les calculs dans un ordre qui ne casse pas les dpendances. Il existe au moins deux mthodes pour parallliser ce nid de boucles : lalgorithme de lhyperplan et celui du software pipelining.
16 septembre 2013
110 / 234
Algorithme de lhyperplan
Comment exhiber du paralllisme ? Le principe est simple : nous allons travailler sur des hyperplans dquation : i + j = cste qui correspondent des diagonales de la matrice. Sur un hyperplan donn, les mises jour des lments de cet hyperplan sont indpendantes les unes des autres, donc ces oprations peuvent tre ralises en parallle. Par contre, il existe une relation de dpendance entre les hyperplans ; on ne peut pas mettre jour dlments de lhyperplan Hn tant que la mise jour de ceux de lhyperplan Hn1 nest pas termine.
Algorithme de lhyperplan (2)

Rcriture du code Lalgorithme de lhyperplan ncessite donc une rcriture du code, avec une boucle externe sur les hyperplans (non parallle cause des dpendances entre hyperplans) et une boucle parallle interne sur les lments appartenant lhyperplan qui peuvent tre mis jour dans un ordre quelconque. Le code peut se rcrire sous la forme suivante :
do h = 1,nbre_hyperplan ! boucle non //, dpendance entre les hyperplans call calcul(INDI,INDJ,h) ! calcul tab. dindices i et j des lments des hype do e = 1,nbre_element_hyperplan ! boucle sur le nombre dlments de lhyperp i = INDI(e) j = INDJ(e) V(i,j) =(V(i,j) + V(i-1,j) + V(i,j-1))/3 ! MAJ de llment V(i,j) enddo enddo
Quelques remarques complmentaires Une fois le code rcrit, la paralllisation est trs simple, la boucle interne tant parallle. Nous navons pas eu besoin davoir recours des synchronisations nes pour implmenter lalgorithme de lhyperplan. Les performances obtenues ne sont hlas pas optimales, la cause principale est la mdiocre utilisation des caches due laccs en diagonale (donc non contigu en mmoire) des lments de la matrice V .
Algorithme software pipelining

Comment exhiber du paralllisme ? Le principe est simple : nous allons parallliser par blocs la boucle la plus interne et jouer sur les itrations de la boucle externe pour veiller ne pas casser de dpendance en synchronisant nement les threads entre eux. On dcoupe la matrice en tranches horizontales et on attribue chaque tranche un thread. Les dpendances de lalgorithme nous imposent alors que le thread 0 doit toujours traiter une itration de la boucle externe j qui doit tre suprieure celle du thread 1, qui elle-mme doit tre suprieure celle du thread 2 et ainsi de suite... Si on ne respecte pas cette condition, on casse des dpendances ! Concrtement, lorsquun thread a termin de traiter la j eme colonne de son domaine, il doit vrier avant de continuer que le thread qui le prcde a lui-mme termin de traiter la colonne suivante (i.e. la j + 1eme ). Si ce nest pas le cas, il faut le faire attendre jusqu ce que cette condition soit remplie. Pour implmenter cet algorithme, il faut constamment synchroniser les threads deux deux et ne librer un thread que lorsque la condition nonce prcdemment est ralise.
16 septembre 2013
113 / 234
Algorithme software pipelining (2)

Les dpendances...
16 septembre 2013
114 / 234
Algorithme software pipelining (3)
Implmentation Finalement, limplmentation de cette mthode peut se faire de la faon suivante :

myOMPRank = ... nbOMPThrds = ... call calcul_borne(iDeb,iFin) do j= 2,n ! On bloque le thread (sauf le 0) tant que le ! prcedent na pas fini le traitement ! de litration j+1 call sync(myOMPRank,j) ! Boucle // distribue sur les threads do i = iDeb,iFin ! MAJ de llment V(i,j) V(i,j) =(V(i,j) + V(i-1,j) + V(i,j-1))/3 enddo enddo
16 septembre 2013
115 / 234
Performances MPI/OpenMP-FG/OpenMP-CG
Caractristiques du code et de la machine cible Les tests de performance ont t faits avec le code dhydrodynamique HYDRO (celui utilis dans les TP) La machine cible est un nud mmoire partage de Vargas (IBM SP6, 32 curs par nud) On a compar trois versions paralllises dHYDRO :
1 2 3
Une version paralllise avec MPI, dcomposition de domaine 2D, utilisation de types drivs, pas de recouvrement calculs-communications, Une version paralllise avec OpenMP de type Fine-grain, scheduling de type STATIC, Une version paralllise avec OpenMP de type Coarse-grain, dcomposition de domaine 2D, synchronisation thread thread pour grer les dpendances.
16 septembre 2013
116 / 234
Caractristiques des jeux de donnes utiliss On a utilis trois jeux de tests, de mme taille totale (i.e. mme nombre total de points du domaine), mais de rpartitions diffrentes dans les deux directions x et y :
1 2 3
Domaine allong suivant la direction y : nx = 1000 et ny = 100000, Domaine carr : nx = ny = 10000, Domaine allong suivant la direction x : nx = 100000 et ny = 1000.
16 septembre 2013
117 / 234
Rsultats pour le domaine nx = 100000, ny = 1000
Tps (s) mpi2D ompfg ompcg Mono 361.4 361.4 361.4 1 core 383.8 371.6 350.4 2 cores 170.9 193.2 177.3 4 cores 91.4 98.4 85.3 8 cores 42.0 51.0 43.8 16 cores 23.0 32.2 23.4 24 cores 14.4 24.6 16.9 32 co. 13.6 20.2 12.0
16 septembre 2013
118 / 234
16 septembre 2013
119 / 234
16 septembre 2013
120 / 234
Analyse des rsultats (1)
Version OpenMP Fine-grain Bien quon travaille sur des domaines de taille identique, les performances obtenues sur un seul cur varient du simple au triple. La raison est chercher du ct de la bonne utilisation ou non des caches. Quel que soit le jeu de test et jusqu 4 curs, les trois versions donnent des performances plus ou moins comparables. Au-del de 4 curs, la version OpenMP FG souffre dun problme dextensibilit dgrade compare aux versions MPI et OpenMP CG. En consquence, hormis pour un nombre limit de curs, la version OpenMP FG est toujours largement domine par les versions MPI ou OpenMP CG, mme si elle est extensible de faon rgulire mais limite jusqu 32 curs.
16 septembre 2013
121 / 234
Analyse des rsultats (2)
Versions MPI et OpenMP Coarse-grain Jusqu 24 curs, les versions MPI et OpenMP CG ont des extensibilits comparables et parfaites, parfois mme super-linaires (i.e. meilleur rutilisation des caches au fur et mesure que la taille des sous-domaines locaux diminue). Au-del de 24 curs, la version MPI semble marquer le pas, alors que la version OpenMP CG continue tre parfaitement extensible. Sur 32 curs, cest toujours la version OpenMP CG qui donne les meilleurs rsultats. Attention cependant, la version MPI peut encore tre optimise en implmentant par exemple le recouvrement calculs-communications, ce qui lui permettrait peut-tre dtre extensible au-del de 24 curs...
16 septembre 2013
122 / 234
Conclusions
La gnralisation des machines mmoire partage ainsi que laugmentation du nombre de curs disponibles au sein dun nud demande ce que lon reconsidre la faon dont on programme les applications. Au sein dun nud, si on recherche la performance maximale, cest OpenMP version Coarse-grain quil faut utiliser. Cela ncessite un gros investissement et cest au moins aussi compliqu implmenter quune version MPI. Le dbogage est particulirement complexe. Cette approche est rserver aux spcialistes qui matrisent parfaitement le paralllisme et ses piges. La simplicit dutilisation et la rapidit dimplmentation dune version OpenMP Fine-grain sont ses principaux avantages. condition de bien coder (minimisation des barrires de synchronisation et des rgions parallles), les performances selon le type dalgorithme (en particulier selon la granularit) peuvent aller de moyen relativement bon. Le dbogage reste l encore particulirement complexe. Cette approche sadresse tous. MPI obtient de bonnes performances sur un nud mmoire partage, mais OpenMP version CG le surclasse en terme dextensibilit. Il peut cependant tre encore optimis en implmentant le recouvrement calculs-communications. Il reste de toute faon indispensable ds quil faut aller au-del de lutilisation dun simple nud...
16 septembre 2013
124 / 234
Sommaire I
5
Programmation hybride Dnitions Raisons pour faire de la programmation hybride Applications pouvant en tirer parti MPI et le multithreading MPI et OpenMP Adquation larchitecture : laspect gain mmoire Adquation larchitecture : laspect rseau Etude de cas : Multi-Zone NAS Parallel Benchmark Etude de cas : Poisson3D
16 septembre 2013
125 / 234
Dnitions
Dnitions La programmation hybride parallle consiste mlanger plusieurs paradigmes de programmation parallle dans le but de tirer parti des avantages des diffrentes approches. Gnralement, MPI est utilis au niveau des processus et un autre paradigme (OpenMP, pthreads, langages PGAS, UPC...) lintrieur de chaque processus. Dans cette formation, nous traitons exclusivement de lutilisation dOpenMP avec MPI.
16 septembre 2013
126 / 234
Schma de principe
16 septembre 2013
127 / 234
Avantages de la programmation hybride (1) Meilleure extensibilit par une rduction du nombre de messages MPI, du nombre de processus impliqus dans des communications collectives (MPI_Alltoall nest pas trs extensible) et par un meilleur quilibrage de charge. Meilleure adquation larchitecture des calculateurs modernes (nuds mmoire partage interconnects, machines NUMA...), alors que MPI seul est une approche at. Optimisation de la consommation de mmoire totale (grce lapproche mmoire partage OpenMP, gain au niveau des donnes rpliques dans les processus MPI et de la mmoire utilise par la bibliothque MPI elle-mme). Rduction de lempreinte mmoire lorsque la taille de certaines structures de donnes dpend directement du nombre de processus MPI. Peut lever certaines limitations algorithmiques (dcoupage maximum dans une direction par exemple). Amlioration des performances de certains algorithmes en rduisant le nombre de processus MPI (moins de domaines = meilleur prconditionneur si on laisse tomber les contributions des autres domaines). Moins daccs simultans en entres-sorties et taille moyenne des accs plus grande. Cela entrane moins de charge sur les serveurs de mta-donnes avec des requtes de tailles plus adaptes. Les gains potentiels sur une application massivement parallle peuvent tre importants.
Raisons pour faire de la programmation hybride

Avantages de la programmation hybride (2) Moins de chiers grer si on utilise une approche o le nombre de chiers est proportionnel au nombre de processus MPI (approche trs fortement dconseille dans un cadre de paralllisme massif). Certaines architectures ncessitent de lancer plusieurs threads (ou processus) par cur pour utiliser correctement les units de calcul. Un code parallle MPI est une succession de phases de calcul et de communication. La granularit dun code est dnie comme le rapport moyen entre deux phases successives de calcul et de communication. Plus la granularit dun code est importante, plus il est extensible. Compare lapproche pure MPI, lapproche hybride augmente signicativement la granularit et donc lextensibilit des codes. Inconvnients de la programmation hybride Complexit et niveau dexpertise accrus. Ncessit davoir de bonnes performances MPI ET OpenMP (la loi dAmdahl sapplique sparment aux 2 approches). Gains en performances non garantis (surcots supplmentaires...).
Applications pouvant en tirer parti
Applications pouvant en tirer parti Codes ayant une extensibilit MPI limite (par des MPI_Alltoall par exemple). Codes ncessitant de lquilibrage de charge dynamique. Codes limits par la quantit de mmoire et ayant de nombreuses donnes rpliques entre les processus ou ayant des structures de donnes dpendant du nombre de processus pour leur dimension. Bibliothque MPI locale peu performante pour les communications intra-nud. De nombreuses applications massivement parallle. Codes travaillant sur des problmes paralllisme grain n ou un mlange grain n et gros grain. Codes limits par lextensibilit de leurs algorithmes. ...
16 septembre 2013
130 / 234
MPI et le multithreading
Support des threads dans MPI La norme MPI prvoit un sous-programme particulier pour remplacer MPI_Init lorsque lapplication MPI est multithreade. Il sagit de MPI_Init_thread. La norme nimpose aucun niveau minimum de support des threads. Certaines architectures et/ou implmentations peuvent donc navoir aucun support pour les applications multithreades. Les rangs identient uniquement les processus, pas les threads qui ne peuvent tre prciss dans les communications. Nimporte quel thread peut faire des appels MPI (dpend du niveau de support). Nimporte quel thread dun processus MPI donn peut recevoir un message envoy ce processus (dpend du niveau de support). Les appels bloquants ne bloquent que le thread concern. Lappel MPI_Finalize doit tre fait par le thread qui a appel MPI_Init_thread et lorsque lensemble des threads du processus ont ni leurs appels MPI.
16 septembre 2013
131 / 234
MPI_Init_thread int MPI_Init_thread(int *argc, char *((*argv)[]), int required, int *provided) MPI_INIT_THREAD(REQUIRED, PROVIDED, IERROR) Le niveau de support demand est fourni dans la variable required. Le niveau effectivement obtenu (et qui peut tre moindre que demand) est rcupr dans provided. MPI_THREAD_SINGLE : seul un thread par processus peut sexcuter MPI_THREAD_FUNNELED : lapplication peut lancer plusieurs threads par processus, mais seul le thread principal (celui qui a fait lappel MPI_Init_thread) peut faire des appels MPI MPI_THREAD_SERIALIZED : tous les threads peuvent faire des appels MPI, mais un seul la fois MPI_THREAD_MULTIPLE : entirement multithread sans restrictions
16 septembre 2013
132 / 234
Autres sous-programmes MPI MPI_Query_thread retourne le niveau de support du processus appellant : int MPI_Query_thread(int *provided) MPI_QUERY_THREAD(PROVIDED, IERROR) MPI_Is_thread_main retourne si le thread appellant est le thread principal ou pas (important si niveau MPI_THREAD_FUNNELED et pour lappel MPI_Finalize) : int MPI_Is_thread_main(int *flag) MPI_IS_THREAD_MAIN(FLAG, IERROR)
16 septembre 2013
133 / 234
Restrictions sur les appels MPI collectifs En mode MPI_THREAD_MULTIPLE, lutilisateur doit sassurer que les oprations collectives sur le mme communicateur, fentre mmoire ou descripteur de chier sont correctement ordonnes entre les diffrents threads. Cela implique quil est interdit davoir plusieurs threads par processus faisant des appels collectifs avec le mme communicateur sans sassurer que tous les processus les font dans le mme ordre. On ne peut donc pas avoir un instant donn 2 threads qui font chacun un appel collectif avec le mme communicateur (que les appels soient diffrents ou pas). Par exemple, si plusieurs threads font un appel MPI_Barrier avec MPI_COMM_WORLD, lapplication peut se bloquer (cela se vrie facilement sur Babel et Vargas). 2 threads appelant chacun un MPI_Allreduce (avec la mme opration de rduction ou pas) peuvent obtenir des rsultats faux. 2 appels collectifs diffrents ne peuvent pas non plus tre utiliss (un MPI_Reduce et MPI_Bcast par exemple).
16 septembre 2013
134 / 234
Restrictions sur les appels MPI collectifs Pour viter ce genre de difcults, il existe plusieurs possibilits : Imposer lordre des appels en synchronisant les diffrents threads lintrieur de chaque processus MPI, Utiliser des communicateurs diffrents pour chaque appel collectif, Ne faire des appels collectifs que sur un seul thread par processus. Remarque : en mode MPI_THREAD_SERIALIZED, le problme ne devrait pas exister car lutilisateur doit obligatoirement sassurer qu un instant donn au maximum seul un thread par processus est impliqu dans un appel MPI (collectif ou pas). Attention, lordre des appels doit nanmoins tre respect.
16 septembre 2013
135 / 234
MPI et OpenMP
Implications des diffrents niveaux de support Le niveau de support du multithreading fourni par la bibliothque MPI impose certaines conditions et restrictions lutilisation dOpenMP : MPI_THREAD_SINGLE : OpenMP ne peut pas tre utilis MPI_THREAD_FUNNELED : les appels MPI doivent tre faits en dehors des rgions parallles OpenMP ou dans les regions OpenMP master ou dans des zones protges par un appel MPI_Is_thread_main MPI_THREAD_SERIALIZED : dans les rgions parallles OpenMP, les appels MPI doivent tre raliss dans des sections critical (si ncessaire pour garantir un seul appel MPI simultan) MPI_THREAD_MULTIPLE : aucune restriction
16 septembre 2013
136 / 234
MPI et OpenMP
Etat des implmentations actuelles Implmentation MPICH OpenMPI IBM Blue Gene/Q IBM PEMPI BullxMPI Intel - MPI SGI - MPT Niveau support MPI_THREAD_MULTIPLE MPI_THREAD_MULTIPLE MPI_THREAD_MULTIPLE MPI_THREAD_MULTIPLE MPI_THREAD_FUNNELED MPI_THREAD_MULTIPLE MPI_THREAD_MULTIPLE Remarques Doit tre compil avec loption enable-mpi-threads
Utiliser -mt_mpi Utiliser -lmpi_mt
16 septembre 2013
137 / 234
Programmation hybride, laspect gain mmoire

Pourquoi un gain mmoire ? La programmation hybride permet doptimiser ladquation du code larchitecture cible. Cette dernire est gnralement constitue de nuds mmoire partage (SMP) relis entre eux par un rseau dinterconnexion. Lintrt de la mmoire partage au sein dun nud est quil nest pas ncessaire de dupliquer des donnes pour se les changer. Chaque thread a visibilit sur les donnes SHARED. Les mailles fantmes ou halo, introduites pour simplier la programmation de codes MPI utilisant une dcomposition de domaine, nont plus lieu dtre lintrieur du nud SMP. Seules les mailles fantmes associes aux communications inter-nuds sont ncessaires. Le gain associ la disparition des mailles fantmes intra-nud est loin dtre ngligeable. Il dpend fortement de lordre de la mthode utilise, du type de domaine (2D ou 3D), du type de dcomposition de domaine (suivant une seule dimension, suivant toutes les dimensions) et du nombre de curs du nud SMP. Lempreinte mmoire des buffers systmes associs MPI est non ngligeable et crot avec le nombre de processus. Par exemple, pour un rseau Inniband avec 65000 processus MPI, lempreinte mmoire des buffers systmes atteint 300 Mo par processus, soit pratiquement 20 To au total !
Exemple domaine 2D, dcomposition suivant les 2 directions
16 septembre 2013
139 / 234
Extrapolation sur un domaine 3D Essayons de calculer, en fonction de lordre de la mthode numrique (h) et du nombre de curs du nud SMP (c ), le gain mmoire relatif obtenu en utilisant une version hybride au lieu dune version at MPI dun code 3D paralllis par une technique de dcomposition de domaine suivant ses trois dimensions. On prendra les hypothses suivantes :
On fait varier lordre de la mthode numrique h de 1 10. On fait varier le nombre de curs c du nud SMP de 1 128. Pour dimensionner le problme, on suppose quon a accs 64 Go de mmoire
partage sur le nud.
Le rsultat de la simulation est prsent dans le transparent suivant. Les isovaleurs 10%, 20% et 50% sont reprsentes par des lignes blanches sur la surface rsultat.
16 septembre 2013
140 / 234

Extrapolation sur un domaine 3D
16 septembre 2013
141 / 234
Gain mmoire effectif sur quelques codes applicatifs Source : Mixed Mode Programming on HECToR , Anastasios Stathopoulos, August 22, 2010, MSc in High Performance Computing, EPCC Machine cible : HECToR CRAY XT6. 1856 Compute Nodes (CN), chacun compos de deux processeurs AMD 2.1 GHz 12 curs se partageant 32 Go de mmoire, pour un total de 44544 curs, 58 To de mmoire et une performance crte de 373 Top/s. Rsultats, la mmoire par node est exprime en Mo : Code CPMD BQCD SP-MZ IRS Jacobi Version pure MPI Nbre MPI Mm./Node 1152 2400 3072 3500 4608 2800 2592 2600 2304 3850 Version hybride MPI x threads Mm./Node 48 x 24 500 128 x 24 1500 192 x 24 1200 108 x 24 900 96 x 24 2100 Gain mmoire 4.8 2.3 2.3 2.9 1.8
16 septembre 2013
142 / 234
Gain mmoire effectif sur quelques codes applicatifs Source : Performance evaluations of gyrokinetic Eulerian code GT5D on massively parallel multi-core platforms , Yasuhiro Idomura et Sbastien Jolliet, SC11 Excutions sur 4096 curs Machine utilise : Fujitsu BX900 avec des processeurs Nehalem-EP 2,93 GHz (8 curs et 24 Gio par nud) Toutes les tailles sont donnes en Tio Systme BX900 MPI pur Total (code+sys) 5.40 (3.40+2.00) 4 threads/prc Total (code+sys) Gain 2.83 (2.39+0.44) 1.9 8 threads/prc Total (code+sys) Gain 2.32 (2.16+0.16) 2.3
16 septembre 2013
143 / 234
Conclusion sur les aspects gains mmoire Trop souvent, cet aspect est oubli lorsquon parle de la programmation hybride. Pourtant, les gains potentiels sont trs importants et pourraient tre mis prot pour augmenter la taille des problmes simuler ! Plusieurs raisons font que le diffrentiel (MPI vs. Hybride) va samplier de plus en plus rapidement pour les machines de prochaine gnration :
1 2
La multiplication du nombre total de curs, La multiplication rapide du nombre de curs disponibles au sein dun nud ainsi que la gnralisation de lhyperthreading ou du SMT (possibilit dexcuter simultanment plusieurs threads sur un seul cur), La gnralisation de mthodes numriques dordre lev (le cot du calcul brut tant de moins en moins lev grce notamment aux acclrateurs matriels)
Ce qui va rendre quasi obligatoire le passage la programmation hybride...
16 septembre 2013
144 / 234
Utilisation optimale du rseau dinterconnexion
Comment optimiser lutilisation du rseau dinterconnexion inter-nud ? Lapproche hybride vise utiliser au mieux les ressources matrielles disponibles (mmoire partage, hirarchie mmoire, rseau de communication), Une des difcults de la programmation hybride est de gnrer un nombre sufsant de ux de communications de faon utiliser au mieux le rseau de commmunication inter-nud. En effet, les dbits des rseaux dinterconnexion inter-nuds des architectures rcentes sont levs (dbit crte de 8 Go/s bidirectionnel sur Vargas par exemple) et un seul ux de donnes ne peut le saturer, seule une fraction du rseau est rllement utilise, le reste tant perdu... Dveloppement IDRIS dun petit benchmark SBPR (Saturation Bande Passante Rseau), simple test de PingPong en parallle, visant dterminer le nombre de ux concurrents ncssaires pour saturer le rseau.
16 septembre 2013
145 / 234

SBPR version MPI_THREAD_FUNNELED Approche MPI_THREAD_FUNNELED : On augmente la bande passante rseau rellement utilise en augmentant le nombre de processus MPI par nud (i.e. on gnre autant de ux de communication en parallle que de processus MPI par nud). La solution basique consistant utiliser autant de threads OpenMP que de curs au sein dun nud et autant de processus MPI que de nuds nest gnralement pas la meilleure les ressources ntant pas utilises de faon optimale, en particulier le rseau... On cherche dterminer la valeur optimale du ratio entre le nombre de processus MPI par nud et le nombre de threads OpenMP par processus MPI. Plus ce ratio est grand, meilleur est le dbit du rseau inter-nud, mais moins bonne est la granularit... Un compromis est trouver. Le nombre de processus MPI (i.e. de ux de donnes grer simultanment) ncessaire pour saturer le rseau varie fortement dune architecture une autre. Cette valeur pourra tre un bon indicateur du ratio optimal du nombre de processus MPI/nombre de threads OpenMP par nud dune application hybride.
16 septembre 2013
146 / 234
SBPR MPI_THREAD_FUNNELED : exemple sur un nud SMP 4 curs (BG/P)
16 septembre 2013
147 / 234

SBPR MPI_THREAD_FUNNELED : exemple sur un nud SMP 4 curs (BG/P)
16 septembre 2013
148 / 234

SBPR version MPI_THREAD_MULTIPLE Approche MPI_THREAD_MULTIPLE : On augmente la bande passante rseau rllement utilise en augmentant le nombre de threads OpenMP qui participent aux communications. On a un unique processus MPI par nud, on cherche le nombre minimum de threads de communication ncessaire pour saturer le rseau. SBPR MPI_THREAD_MULTIPLE : exemple sur un nud SMP 4 curs (BG/P)
16 septembre 2013
149 / 234

SBPR MPI_THREAD_MULTIPLE : exemple sur un nud SMP 4 curs (BG/P)
16 septembre 2013
150 / 234

SBPR MPI_THREAD_FUNNELED Rsultats sur Vargas 4 liens en // Inniband DDR, dbit crte 8 Go/s.
MPI x OMP par nud 1 x 32 2 x 16 4x8 8x4 16 x 2 32 x 1 Dbit cumul en Mo/s Message de 1 Mo 1016 2043 3895 6429 7287 7412 Dbit cumul en Mo/s Message de 10 Mo 1035 2084 3956 6557 7345 7089 Dbit cumul en Mo/s Message de 100 Mo 959 1803 3553 5991 7287 4815
Interprtations Avec 1 seul ux, on nutilise quun huitime de la bande passante rseau inter-nud. La saturation des liens rseaux inter-nud de Vargas commence apparatre clairement partir de 8 ux en parallle (i.e. 8 processus MPI par nud). La saturation est totale avec 16 ux en parallle (i.e. 16 processus MPI par nud). Avec 16 ux en parallle, on obtient un dbit de 7,35 Go/s, soit plus de 90% de la bande passante rseau crte inter-nud disponible !
SBPR MPI_THREAD_FUNNELED Rsultats sur Babel Dbit crte 425 Mo/s

MPI x OMP par nud SMP (1 x 4) DUAL (2 x 2) VN (4 x 1) Dbit cumul en Mo/s Message de 1 Mo 373.5 374.1 374.7 Dbit cumul en Mo/s Message de 10 Mo 374.8 374.9 375.0 Dbit cumul en Mo/s Message de 100 Mo 375.0 375.0 375.0
Interprtations Lutilisation dun seul ux de donnes (i.e. 1 seul processus MPI par nud) suft saturer totalement le rseau dinterconnexion entre deux nuds voisins. Le dbit atteint est de 375 Mo/s, soit 88% de la bande passante crte rseau inter-nud.
16 septembre 2013
152 / 234

SBPR MPI_THREAD_MULTIPLE Rsultats sur Vargas 4 liens en // Inniband DDR, dbit crte 8 Go/s.
MPI x OMP par nud 1 x 32 (1 ux) 1 x 32 (2 ux //) 1 x 32 (4 ux //) 1 x 32 (8 ux //) 1 x 32 (16 ux //) 1 x 32 (32 ux //) Dbit cumul en Mo/s Message de 1 Mo 548.1 818.6 938.6 964.4 745.1 362.2 Dbit cumul en Mo/s Message de 10 Mo 968.1 1125 1114 1149 1040 825.1 Dbit cumul en Mo/s Message de 100 Mo 967.4 1016 1031 1103 1004 919.9
Interprtations Les performances des versions MPI_THREAD_MULTIPLE et MPI_THREAD_FUNNELED sont trs diffrentes, le dbit naugmente plus avec le nombre de ux en parallle et reste constant. Avec 1 seul ux comme avec plusieurs, on nutilise toujours quun huitime de la bande passante rseau inter-nud. Elle nest de ce fait jamais sature ! Cette approche MPI_THREAD_MULTIPLE (i.e. plusieurs threads communiquant simultanment au sein dun mme processus MPI) nest donc absolument pas adapte la machine Vargas, mieux vaut lui prfrer lapproche MPI_THREAD_FUNNELED.
SBPR MPI_THREAD_MULTIPLE Rsultats sur Babel Dbit crte 425 Mo/s

MPI x OMP par nud SMP (1 ux) SMP (2 ux //) SMP (4 ux //) Dbit cumul en Mo/s Message de 1 Mo 372.9 373.7 374.3 Dbit cumul en Mo/s Message de 10 Mo 374.7 374.8 374.9 Dbit cumul en Mo/s Message de 100 Mo 375.0 375.0 375.0
Interprtations Les performances des versions MPI_THREAD_MULTIPLE et MPI_THREAD_FUNNELED sont comparables. Lutilisation dun seul ux de donnes (i.e. 1 seul thread de communication par nud) suft saturer totalement le rseau dinterconnexion entre deux nuds voisins. Le dbit atteint est de 375 Mo/s, soit 88% de la bande passante crte rseau inter-nud.
16 septembre 2013
154 / 234
Prsentation du benchmark
Description du Multi-Zone NAS Parallel Benchmark Le Multi-Zone NAS Parallel Benchmark est un ensemble de programmes de tests de performances pour machines parallles dvelopp par la NASA. Ces codes utilisent des algorithmes proches de certains codes de CFD. La version multi-zone fournit 3 applications diffrentes avec 8 tailles de problme diffrentes. Benchmark utilis assez couramment. Les sources sont disponibles ladresse : http://www.nas.nasa.gov/Resources/Software/software.html.
16 septembre 2013
155 / 234
Prsentation du benchmark
Application choisie : BT-MZ BT-MZ : mthode de rsolution tridiagonale par blocs. La taille des zones est trs variable. Mauvais quilibrage de charge. Lapproche hybride devrait amliorer la situation. Application choisie : SP-MZ SP-MZ : mthode de rsolution pentadiagonale scalaire. Toutes les tailles de zones sont gales. Parfait quilibrage de charge. Lapproche hybride ne devrait rien apporter sur ce point. Tailles de problme slectionnes Classe D : 1024 zones (et donc limit 1024 processus MPI), 1632 x 1216 x 34 points de maillage (13 Gio) Classe E : 4096 zones (et donc limit 4096 processus MPI), 4224 x 3456 x 92 points de maillage (250 Gio)
16 septembre 2013
156 / 234
16 septembre 2013
157 / 234
16 septembre 2013
158 / 234
Analyse des rsultats
Analyse des rsultats : BT-MZ La version hybride est quivalente la version MPI pour un nombre de processus pas trop grand. Lorsque le dsquilibrage de charge apparat en MPI pur ( partir de 512 processus pour la classe D et de 2048 pour la classe E), la version hybride permet de garder une trs bonne extensibilit en rduisant le nombre de processus. La limite de 1024 zones en classe D et de 4096 en classe E limite respectivement 1024 et 4096 processus MPI, mais lajout dOpenMP permet daller bien plus loin en nombre de curs utiliss tout en obtenant une excellente extensibilit.
16 septembre 2013
159 / 234
Analyse des rsultats
Analyse des rsultats : SP-MZ Bien que nayant pas de dsquilibrage de charge, ce benchmark prote dans certains cas du caractre hybride de lapplication. La limite de 1024 zones en classe D et de 4096 en classe E limite respectivement 1024 et 4096 processus MPI, mais lajout dOpenMP permet daller bien plus loin en nombre de curs utiliss tout en obtenant une excellente extensibilit.
16 septembre 2013
160 / 234
Sommaire Poisson3D I
5
Programmation hybride Dnitions Raisons pour faire de la programmation hybride Applications pouvant en tirer parti MPI et le multithreading MPI et OpenMP Adquation larchitecture : laspect gain mmoire Adquation larchitecture : laspect rseau Etude de cas : Multi-Zone NAS Parallel Benchmark Etude de cas : Poisson3D
16 septembre 2013
161 / 234
Introduction loptimisation de codes
Dnition Optimiser un code de calcul consiste rduire ses besoins en ressources. Ces dernires sont diverses mais gnralement on parle du temps de restitution. La consommation de mmoire ou despace disque entrent galement dans cette catgorie.
16 septembre 2013
162 / 234

Pourquoi optimiser ? Optimiser une application peut apporter un certain nombre davantages : Obtention plus rapide des rsultats par une diminution du temps de restitution ; Possibilit dobtenir plus de rsultats avec les heures qui vous ont t attribues ; Possibilit deffectuer de plus gros calculs ; Meilleure comprhension du code, de larchitecture de la machine et de leurs interactions ; Avantage comptitif par rapport dautres quipes ; Dcouverte et correction de bogues grce la relecture des sources du code. Lamlioration des performances dune application permet galement : Une rduction de la consommation dnergie de vos calculs ; Une meilleure utilisation de la machine (le cot dachat, de maintenance et dutilisation dun supercalculateur nest pas ngligeable). A lIDRIS, chaque heure qui vous est attribue reprsente une dpense pour toute la communaut scientique ; De librer des ressources pour dautres groupes de recherche.
16 septembre 2013
163 / 234
Pourquoi ne pas optimiser ? Insufsance de ressources ou de moyens pour le faire (manque de personnel, de temps, de comptences...) ; Diminution de la portabilit du code (beaucoup doptimisations sont spciques larchitecture de la machine) ; Risque de pertes de performances sur dautres machines ; Diminution de la lisibilit des sources et maintenance plus dlicate ; Risque dintroduction de bogues ; Code non prenne ; Code sufsamment rapide (il ne sert rien doptimiser un code qui fournit dj des rsultats dans un temps acceptable) ; Code dj optimis.
16 septembre 2013
164 / 234
Quand optimiser ? Une application ne doit tre optimise que lorsquelle fonctionne correctement car
risques de nouveaux bogues, rduction lisibilit et comprhension du code et risques doptimisation de procdures qui seront abandonnes ou ne seront pas ou trs
peu utilises ou qui seront totalement rcrites.
Ne se lancer dans loptimisation que si application est trop lente ou ne permet pas de faire tourner de gros calculs dans un temps acceptable. Si vous tes pleinement satisfait des performances de votre application, linvestissement nest peut tre pas ncessaire. Avoir du temps devant soi.
16 septembre 2013
165 / 234
Comment optimiser ? Avant tout : faire un prolage squentiel et parallle avec un jeu de test raliste pour identier les zones critiques Optimiser l o lon consomme le plus de ressources Vrier chaque optimisation : rsultats toujours corrects ? Performances rellement amliores ? Question : si gain faible : garder loptimisation ? Quoi optimiser ? Les performances squentielles Les communications MPI, les performances OpenMP et lextensibilit Les entres/sorties
16 septembre 2013
166 / 234
Optimisation squentielle Algorithmes et conception Bibliothques Compilateur Caches Units de calcul spcialises (SIMD, SSE, Altivec...) Autres
16 septembre 2013
167 / 234
Optimisation des communications MPI, dOpenMP et de lextensibilit Algorithmes et conception Equilibrage de charge Recouvrement calculs/communications Placement des processus Programmation hybride Autres
16 septembre 2013
168 / 234
Optimisation des entres/sorties Ne lire et crire que le ncessaire Rduire la prcision (ottants simple prcision au lieu de double) Entres/sorties parallles Bibilothques (MPI-I/O, HDF5, NetCDF, Parallel-NetCDF...) Hints MPI-I/O Autres
16 septembre 2013
169 / 234

Prsentation de Poisson3D Poisson3D est une application qui rsout lquation de Poisson sur le domaine cubique [0,1]x[0,1]x[0,1] par une mthode aux diffrences nies avec un solveur Jacobi. 8 > > <
u + + y 2 u (x , y , z ) > > : f (x , y , z ) uexacte (x , y ) 2u x 2
2
2u z2
= f (x , y , z ) dans [0, 1]x[0, 1]x[0, 1] = 0. sur les frontires = 2yz (y 1)(z 1) + 2xz (x 1)(z 1) + 2xy (x 1)(y 1) = xyz (x 1)(y 1)(z 1)
Solveur La discrtisation se fait sur un maillage rgulier dans les trois directions spatiales (pas h = hx = hy = hz ). La solution est calcule par un solveur Jacobi o la solution de litration n + 1 est calcule partir de la solution prcdente de litration n.
n +1 uijk =
1 n n n n n 2 (ui +1jk + uin 1jk + uij +1k + uij 1k + uijk +1 + uijk 1 h fijk ) 6
16 septembre 2013
170 / 234
Structure code initial

1 2
Lecture paramtres Cration de la topologie cartsienne, des structures de donnes MPI (types drivs, liste des voisins...) Initialisation des donnes Boucle sur le solveur
1 2 3 4 5
3 4
Recopie de u n+1 dans u n Echange des donnes sur les frontires inter-processus Calcul de la solution u n+1 Calcul de lerreur Vrication de la convergence
Finalisation (dsallocation structures de donnes et MPI, afchage statistiques)
16 septembre 2013
171 / 234

Dcomposition de domaine 3D Le domaine physique est dcoup dans les 3 directions spatiales.
16 septembre 2013
172 / 234
Etude de cas : Poisson3D sur Babel
Versions 4 versions diffrentes ont t dveloppes :

1 2 3 4
Version MPI pur sans recouvrement calculs-communications Version hybride MPI + OpenMP sans recouvrement calculs-communications Version MPI pur avec recouvrement calculs-communications Version hybride MPI + OpenMP avec recouvrement calculs-communications
Choix des options de compilation Le niveau doptimisation du compilateur a un impact important sur les performances. Les options optimales varient avec la taille du problme tudi, ainsi quavec le nombre de processus et threads excuts. Pour Poisson3D, les options donnant les meilleures performances globales (avec moins de 3% dcart avec chaque meilleur cas) sont -O3 -qarch=450.
16 septembre 2013
173 / 234
Analyse des premiers rsultats Version MPI sans recouv MPI+OMP sans recouv MPI avec recouv MPI+OMP avec recouv 643 8,194 s 11,130 s 7,715 s 12,332 s 1283 95,738 s 111,413 s 91,676 s 89,657 s 2563 64,992 s 60,238 s 60,085 s 46,961 s 5123 42,826 s 38,248 s 52,732 s 37,853 s
Excuts sur 256 curs Blue Gene/P.
Les versions avec recouvrement sont plus rapides que sans en MPI pur sur les petites tailles de problme et cest linverse pour lhybride. Les versions hybrides sont les plus rapides pour les grosses tailles de problme. Trop tt pour en tirer de vraies conclusions (il faudrait aussi faire varier le nombre de curs et tudier lextensibilit).
16 septembre 2013
174 / 234

Effet de la topologie cartsienne Version MPI MPI MPI MPI MPI MPI sans recouv avec recouv avec recouv avec recouv avec recouv avec recouv Topologie 16x4x4 8x8x4 16x4x4 32x4x2 4x16x4 4x4x16 Time (s) 42.826 45.748 52.741 71.131 39.039 36.752 L1 read (Tio) 11.959 11.437 11.501 12.747 11.413 11.126 DDR read (Tio) 9.265 10.716 14.607 18.809 7.823 7.639 Torus send (Gio) 112.873 113.142 112.873 362.979 112.873 37.734
Excuts sur 256 curs Blue Gene/P avec une taille de 5123 .
Leffet du dcoupage de la topologie cartsienne est trs important. Le phnomne semble d des effets de cache. En 5123 , les tableaux u et u _nouveau occupent 8 Mio/cur. Selon la topologie, les accs la mmoire centrale sont trs diffrents (entre 7,6 Tio et 18,8 Tio en lecture). Le temps de restitution semble fortement corrl ces accs. La quantit de donnes circulant sur le tore 3D est trs variable et semble partiellement corrle au temps de restitution.

Forme des sous-domaines (5123 )
16 septembre 2013
176 / 234

Effets de cache Leffet de la forme de la topologie cartsienne sexplique par la disposition dans les caches. Les tableaux u et u _nouveau sont dcoups dans la topologie 16x 4x 4 en (34, 130, 130) et dans la topologie 4x 16x 4 en (130, 34, 130). Dans le calcul du domaine extrieur, le calcul des faces i = cte entrane lutilisation dun seul lement u _nouveau par ligne de cache L3 (qui contient 16 doubles). Les faces i = cte tant 4x plus petites en 4x16x4 quen 16x4x4, une grande partie de lcart vient de l. Pour amliorer lutilisation des caches, on peut calculer dans le domaine extrieur plus de plans i = cte quavant. Topologie 4x16x4 4x16x4 Nplans 1 16 Time (s) 39.143 35.614 Topologie 16x4x4 16x4x4 Nplans 1 16 Time (s) 52.777 41.559
Les tests montrent quen mettre 16 (cd la taille dune ligne de cache L3) sur Babel donne les meilleurs rsultats. Cette taille doit tre rduite si le sous-domaine est petit.

Communications MPI Les tests prcdents donnaient des quantits de donnes envoyes sur le tore 3D variables en fonction de la topologie. Les causes en sont : Les messages envoys entre processus lintrieur dun nud de calcul ne sont pas inclus. Une topologie dans laquelle les processus sont bien placs voit donc la quantit de donnes envoyes sur le rseau diminuer. Les mesures incluent aussi le trac de transit travers chaque nud. Un message envoy un processus situ sur un nud non-adjacent celui de lmetteur sera donc mesur plusieurs fois (il gnre un rel trac et produit de la contention sur les liens rseaux). Version MPI MPI MPI MPI MPI MPI sans recouv avec recouv avec recouv avec recouv avec recouv avec recouv Topologie 16x4x4 8x8x4 16x4x4 32x4x2 4x16x4 4x4x16 Time (s) 42.826 45.748 52.741 71.131 39.039 36.752 L1 read (Tio) 11.959 11.437 11.501 12.747 11.413 11.126 DDR read (Tio) 9.265 10.716 14.607 18.809 7.823 7.639 Torus send (Gio) 112.873 113.142 112.873 362.979 112.873 37.734
16 septembre 2013
178 / 234
Version optimise sans recouvrement Intgration du calcul de lerreur dans la boucle de calcul principale (meilleure rutilisation des caches). Essai dune version avec utilisation de pointeurs pour viter la recopie de u_nouveau dans u chaque itration. Rsultat : 43,347 s avec pointeurs et 37,879 s sans pointeurs. Lutilisation des pointeurs Fortran dgrade les performances malgr les conomies de recopies. Pour viter la recopie, une autre approche a t suivie : on calcule 2 itrations successives en alternant u et u_nouveau dans les phases de calcul et de communication (on passe ainsi de 37,892 s 33,323 s). On peut galement ne calculer lerreur quune fois sur 2 (on passe de 33,323 s 29,885 s) Passage de reorder true dans MPI_Cart_create
16 septembre 2013
179 / 234
Comportement compilateur avec -qsmp=omp Un test montre que la version hybride avec un seul thread par processus est 7% plus rapide que la version MPI pure (27,923 s au lieu de 29,863 s). Aprs instrumentation avec libhpcidris, on constate que le nombre doprations est plus petit dans la routine calcul_and_error (-8.2%) et que les accs en lecture sur le cache L1 sont galement rduits (-15.5% dans calcul et -9.4% dans calcul_and_error). En recompilant la version MPI pure avec loption -qsmp=omp (et en commentant toutes les directives OpenMP), on retrouve les performances de la version hybride. En fait, les boucles internes sont droules (3 fois pour calcul_and_error et 4 fois pour calcul) si on active -qsmp=omp.
16 septembre 2013
180 / 234
Version hybride avec recouvrement Difcults rencontres : La routine end_communication pouvait tre appelle AVANT la n de la routine start_communication (appels faits par diffrents threads) ! Ce phnomne apparaissait avec un schedule static. Ajout dune variable qui sert de verrou pour dbloquer le end_communication (avec des ushs sur celle-ci). Pour pouvoir mettre des NOWAIT entre les 6 boucles de calcul_and_error_ext, il a t ncessaire de crer 6 variables de rduction intermdiaires et de faire manuellement une recherche de la valeur maximale la n de la routine. Il nest pas trivial de choisir o lon met des NOWAIT ou pas. Le risque derreur est lev. Pour que ce programme fonctionne, il faut sassurer que MPI supporte le mode MPI_THREAD_MULTIPLE.
16 septembre 2013
181 / 234
Version hybride avec recouvrement Rsultats (5123 sur 256 curs) : Version MPI MPI+OMP MPI+OMP MPI+OMP scheduling static dynamic guided Time (s) 28.458 28.121 24.648 24.247
Encourageant : la version hybride avec recouvrement et un scheduling dynamique lemporte (pour ce cas test et ce nombre de curs).
16 septembre 2013
182 / 234

Extensibilit Poisson3D 1283
16 septembre 2013
183 / 234

16 septembre 2013
184 / 234

16 septembre 2013
185 / 234

16 septembre 2013
186 / 234
Effets de cache sur les types drivs : analyse La version hybride est presque toujours plus lente que la version MPI pure. A nombre de curs gal, les communications prennent 2 fois plus de temps dans la version hybride (2563 sur 16 curs). La perte de temps vient de lenvoi des messages utilisant les types drivs les plus discontigus en mmoire (plans YZ). La construction de ces types drivs nutilise quun seul lment par ligne de cache. En hybride, la communication et donc le remplissage du type driv est faite par un seul thread par processus. un seul ux en lecture (ou criture) en mmoire par nud de calcul. Lunit de prefetching nest capable de stocker que 2 lignes de cache L3 par ux. En MPI pur, 4 processus par nud lisent ou crivent simultanment (sur des faces 4 fois plus petites). 4 ux simultans et donc remplissage plus rapide
16 septembre 2013
187 / 234
Effets de cache sur les types drivs : solution Remplacement des types drivs par des tableaux faces 2D remplis manuellement. La copie vers et depuis ces faces est paralllisable en OpenMP. Le remplissage se fait maintenant en parallle comme dans la version MPI pure. Rsultats de quelques tests (5123 ) : 64 curs 256 curs 512 curs MPI std 84.837s 27.657s 16.342s MPI no deriv 84.390s 26.729s 14.913s MPI+OMP std 102.196s 25.977s 16.238s MPI+OMP no deriv 88.527s 22.277s 13.193s
Des amliorations apparaissent aussi sur la version MPI pure.
16 septembre 2013
188 / 234

Amlioration Poisson3D 2563
16 septembre 2013
189 / 234

Amlioration Poisson3D 5123
16 septembre 2013
190 / 234
Constatations Les performances sont meilleures voire nettement meilleures quavant dans presque tous les cas sauf dans la version mixte sur un trs grand nombre de curs et avec des tailles de problme trs petites. Par contre, la version MPI lemporte encore presque toujours. Il semble que le problme est toujours du ct des communications qui prennent plus de temps dans la version hybride.
16 septembre 2013
191 / 234
Optimisation des communications (sans recouvrement avec les calculs) Version nowait1 : envois des messages dans des zones single avec nowait la n et copies vers et depuis les faces 2D (remplaant les types drivs) Version nowait2 : idem avec plusieurs communications simultanes, recouvrement avec les copies sur les faces 2D et rduction des synchronisations (barrires caches dans les end do ou end single par exemple, passage de 7 3 synchronisations) Aprs un nouveau test dextensibilit, on voit que la version mixte lemporte de plus en plus souvent sur la version MPI : 643 jusqu 4 curs 1283 jusqu 64 curs 2563 jusqu 256 curs 5123 jusqu au moins 4096 curs Si lon regarde loccupation mmoire des tableaux de travail, on constate que la transition a lieu au moment o le problme tient compltement dans les caches L3.
16 septembre 2013
192 / 234
Version MPI pure contre hybride
Pas de types drivs, sans recouvrement avec les calculs Versions MPI noderiv_simple et hybride nowait2

Optimisation des communications (avec recouvrement avec les calculs) Dveloppement dune version avec recouvrement calculs-communications sans types drivs. Trois approches diffrentes ont t suivies : Version noderiv_single : un thread pour phase denvoi avec recopie des donnes dans les faces et un thread pour rception et recopie des donnes reues. Version noderiv_multi1 : chaque face est envoye dans une zone single distincte avec la recopie de ses donnes dans lespace mmoire intermdiaire. Des threads diffrents peuvent donc grer les diffrentes communications. Version noderiv_multi2 : les recopies dans les espaces intermdiaires sont faites par tous les threads dans des zones OMP DO. Ensuite, les envois et rceptions sont initis par un seul thread. MPI 8.531 8.855 7.099 MPI+OMP 7.303 10.097 8.336 7.891 7.586 MPI 26.725 28.456 27.642 MPI+OMP 19.926 26.741 24.168 23.446 23.426
No recouv Recouv deriv noderiv_single noderiv_multi1 noderiv_multi2
No recouv Recouv deriv noderiv_single noderiv_multi1 noderiv_multi2
2563 , 2500 itrations sur 256 curs

5123 , 1000 itrations sur 256 curs

16 septembre 2013 194 / 234
16 septembre 2013
195 / 234
16 septembre 2013
196 / 234
Constatations Les versions hybrides sont les plus performantes lorsque la taille du problme augmente. Lavantage des versions hybrides diminue avec le nombre de curs utiliss. Les versions non hybrides semblent lemporter lorsque les tableaux de travail tiennent dans les caches mmoires. Les versions avec recouvrement des communications par des calculs sont les meilleures uniquement pour les tailles de problme rduites et avec un grand nombre de curs peu performants sur des cas ralistes (pour cette application). Ces versions optimises sont bien plus performantes que les anciennes.
16 septembre 2013
197 / 234

Comparaison versions optimises contre versions originales (sans recouvrement)
16 septembre 2013
198 / 234

Comparaison versions optimises contre versions originales (avec recouvrement)
16 septembre 2013
199 / 234

Comparaison versions optimises contre versions originales
16 septembre 2013
200 / 234

Rsum des tapes Choix des options du compilateur La topologie cartsienne a un effet important sur les performances cause deffets sur la rutilisation des caches La topologie cartsienne a un effet sur le volume de communication et donc sur les performances Optimisations squentielles apportes Dveloppement de la version hybride moins bonne que la version MPI pure Suppression des types drivs mieux, mais pas encore sufsant Optimisation des communications de la version hybride encore mieux Conclusions Lobtention de bonnes performances en hybride est possible, mais nest pas triviale. Des gains importants peuvent tre raliss (aussi en MPI pur). Une bonne comprhension de lapplication et de larchitecture matrielle est ncessaire.
Code HYDRO
Prsentation du code HYDRO (1) Cest le code utilis pour les TPs du cours hybride. Code dhydrodynamique, maillage cartsien 2D, mthode volumes nis, rsolution dun problme de Riemann aux interfaces par une mthode de Godunov. Depuis quelques annes, dans le cadre de la veille technologique de lIDRIS, ce code sert de benchmark pour les nouvelles architectures, de la simple carte graphique la machine petaopique. Il sest enrichi au cours des annes avec de nouvelles implmentations (nouveaux langages, nouveaux paradigmes de paralllisation). 1500 lignes de code dans sa version F90 monoprocesseur.
16 septembre 2013
202 / 234
Code HYDRO
Prsentation du code HYDRO (2) Aujourdhui, il existe les versions dhydro suivantes :

Version originale, monoprocesseur F90 (P.-Fr. Lavalle, R. Teyssier) Version monoprocesseur C (G. Colin de Verdire) Version parallle MPI F90 (1D P.-Fr. Lavalle, 2D Ph. Wautelet) Version parallle MPI C (2D Ph. Wautelet) Version parallle OpenMP Fine-grain et Coarse-grain F90 (P.-Fr. Lavalle) Version parallle OpenMP Fine-grain C (P.-Fr. Lavalle) Version parallle hybride MPI2D-OpenMP Coarse-grain (P.-Fr. Lavalle, Ph. Wautelet) Version C GPGPU CUDA, HMPP, OpenCL (G. Colin de Verdire)
Plusieurs autres versions sont en cours de dveloppement : UPC, CAF, PGI accelerator, CUDA Fortran, Pthreads
16 septembre 2013
203 / 234
Rsultats 128 curs Babel

Rsultats pour le domaine nx = 100000, ny = 1000 Time (s) Mode VN Mode DUAL Mode SMP 32 cores 49.12 49.00 49.80 64 cores 24.74 24.39 24.70 128 cores 12.47 12.44 12.19
16 septembre 2013
204 / 234

16 septembre 2013
205 / 234

16 septembre 2013
206 / 234
Rsultats 10 racks Babel - Weak Scaling

Caractristiques des domaines utiliss pour le Weak Scaling Sur 4096 curs, nombre de points total du domaine : 16 108
400000x4000 : domaine tir suivant la premire dimension 40000x40000 : domaine carr 4000x400000 : domaine tir suivant la seconde dimension
Sur 8192 curs, nombre de points total du domaine : 32 108




16 septembre 2013
207 / 234

Rsultats pour le domaine tir suivant la premire dimension Time (s) Mode VN Mode DUAL Mode SMP 4096 cores 6.62 6.21 6.33 8192 cores 7.15 6.46 6.38 16384 cores 8.47 6.75 6.72 32768 cores 13.89 7.85 7.00 40960 c. 19.64 8.75 7.22
Performances compares a la version MPI

P.-Fr. Lavalle P. Wautelet (IDRIS) Programmation hybride
Temps elapsed dexcution

16 septembre 2013 208 / 234

Rsultats pour le domaine carr Time (s) Mode VN Mode DUAL Mode SMP 4096 cores 6.17 6.17 6.24 8192 cores 6.67 6.14 6.19 16384 cores 8.00 6.52 6.33 32768 cores 13.32 7.64 6.57 40960 c. 19.57 8.56 7.19


16 septembre 2013 209 / 234

Rsultats pour le domaine tir suivant la deuxime dimension Time (s) Mode VN Mode DUAL Mode SMP 4096 cores 8.04 8.22 7.33 8192 cores 8.28 8.30 8.58 16384 cores 9.79 8.20 8.61 32768 cores 15.42 9.44 8.43 40960 c. 21.17 12.08 8.64


16 septembre 2013 210 / 234
Rsultats sur 10 racks Babel - Weak Scaling

Interprtation des rsultats Les rsultats du Weak Scaling obtenus en utilisant jusqu 40960 curs de calcul sont trs intressants. De nouveaux phnommes apparaissent avec ce nombre lev de curs. Lextensibilit de la version at MPI montre ses limites. Elle peine scaler jusqu 16384 curs, puis les temps de restitution explosent au-del. Comme on sy attendait, la version hybride DUAL, mais encore plus la version SMP se comportent trs bien jusqu 32768 curs, avec des temps de restitution quasi-constants. Sur 40960 curs, la version SMP afche un trs lger surcot, surcot qui devient signicatif pour la version DUAL. En Weak Scaling, la limite dextensibilit de la version at MPI est de 16384 curs, celle de la version DUAL de 32768 curs et celle de la version SMP nest pas encore atteinte sur 40960 curs ! Sur 40960 curs, la version hybride SMP est entre 2.5 et 3 fois plus rapide que la version pure MPI. Il est clair quavec ce type de mthode de paralllisation (i.e. dcomposition de domaine), le passage lchelle (ici au-dessus de 16K curs) ncessite clairement le recours la paralllisation hybride. Point de salut uniquement avec MPI !
Rsultats 10 racks Babel - Strong Scaling

Rsultats pour le domaine nx = 400000, ny = 4000 Time (s) Mode VN Mode DUAL Mode SMP 4096 cores 6.62 6.21 6.33 8192 cores 4.29 3.34 3.18 16384 cores 4.44 2.03 1.75 32768 cores 8.30 2.40 1.24 40960 c. 13.87 3.13 1.29

Extensibilit jusqu 40960 curs

16 septembre 2013 212 / 234



16 septembre 2013 213 / 234



16 septembre 2013 214 / 234
Rsultats sur 10 racks Babel - Strong Scaling

Interprtation des rsultats Les rsultats du Strong Scaling obtenus en utilisant jusqu 40960 curs de calcul sont trs intressants. L encore, de nouveaux phnommes apparaissent avec ce nombre lev de curs. Lextensibilit de la version at MPI montre trs rapidement ses limites. Elle peine scaler jusqu 8192 curs, puis seffondre au-del. Comme on sy attendait, la version hybride DUAL, mais encore plus la version SMP se comportent trs bien jusqu 16384 curs, avec une acclration parfaitement linaire. La version SMP continue de scaler (de faon non linaire) jusqu 32768 curs, au-del on namliore plus les performances... En Strong Scaling, la limite dextensibilit de la version at MPI est de 8192 curs, alors que celle de la version hybride SMP est de 32768 curs. On retrouve ici le facteur 4 qui correspond au nombre de curs dun nud de la BG/P ! La meilleure version hybride (32768 curs) est entre 2.6 et 3.5 fois plus rapide que la meilleure version pure MPI (8192 curs). Il est clair quavec ce type de mthode de paralllisation (i.e. dcomposition de domaine), le passage lchelle (ici au-dessus de 10K curs) ncessite clairement le recours la paralllisation hybride. Point de salut uniquement avec MPI !
Rsultats sur deux nuds Vargas

MPI x OMP par nud 32 x 1 16 x 2 8x4 4x8 2 x 16 1x 32
Temps en s. Mono 64 cores 361.4 7.00 361.4 6.11 361.4 5.75 361.4 5.61 361.4 5.86 361.4 6.24
La version hybride est toujours plus performante que la version pure MPI. Le gain maximum est suprieur 20% pour les rpartitions 8MPIx4OMP, 4MPIx8OMP et 2MPIx16OMP.
16 septembre 2013
216 / 234
MPI x OMP par nud 32 x 1 16 x 2 8x4 4x8 2 x 16 1 x 32
La version hybride est toujours plus performante que la version pure MPI. Le gain maximum est de lordre 20% pour la rpartition 8MPIx4OMP.
16 septembre 2013
217 / 234
MPI x OMP par nud 32 x 1 16 x 2 8x4 4x8 2 x 16 1 x 32
La version hybride est toujours plus performante que la version pure MPI. Le gain maximum est de lordre 20% pour la rpartition 8MPIx4OMP.
16 septembre 2013
218 / 234
Interprtation des rsultats Quel que soit le type de domaine, les versions at MPI et un processus MPI par nud donnent systmatiquement les moins bons rsultats. Les meilleurs rsultats sont donc obtenus avec la version hybride et une rpartition de 8 processus MPI par nud et 4 threads OpenMP par processus MPI pour les deux derniers cas tests et de 4 processus MPI par nud et 16 threads OpenMP par processus MPI pour le premier cas test. Nous retrouvons ici un ratio (i.e. nombre de processus MPI/nombre de threads OpenMP) proche de celui obtenu lors des tests de saturation du rseau dinterconnexion (dbut de saturation avec 8 processus MPI par nud). Mme avec une taille modeste en terme de nombre de curs utiliss, il est intressant de noter que lapproche hybride lemporte chaque fois, parfois mme avec des gains signicatifs de performance. Cest trs encourageant et cela incite augmenter le nombre de curs utiliss.
16 septembre 2013
219 / 234
Conclusions sur lapproche hybride MPI/OpenMP
Conclusions Approche prenne, base sur des standards reconnus (MPI et OpenMP), cest un investissement long terme. Les avantages de lapproche hybride compars lapproche pure MPI sont nombreux :
Gain mmoire signicatif Gain en performance ( nombre xe de curs dexcution), grce une meilleure
adaptation du code larchitecture cible

Gain en terme dextensibilit, permet de repousser la limite dextensibilit dun code
dun facteur gal au nombre de curs du nud mmoire partage
Ces diffrents gains sont proportionnels au nombre de curs du nud mmoire partage, nombre qui augmentera signicativement court terme (gnralisation des processeurs multi-curs) Seule solution viable permettant de tirer parti des architectures massivement parallles venir (multi-peta, exascale, ...)
16 septembre 2013
220 / 234
Outils
16 septembre 2013
221 / 234
Sommaire I
6
Outils SCALASCA TAU TotalView
16 septembre 2013
222 / 234
SCALASCA
Description SCALASCA est un outil graphique danalyse de performances pour applications parallles. Principales caractristiques : Support de MPI et des applications multithreades/OpenMP Modes prolage ou prise de trace (limit MPI_THREAD_FUNNELED pour les traces) Identication/analyse automatique des problmes courants de performance (en mode trace) Nombre de processus illimit Support des compteurs hardware (via PAPI) Utilisation Compiler votre application avec skin f90 (ou autre compilateur) Excuter avec scan mpirun. Option -t pour le mode trace. Visualiser les rsultats avec square
16 septembre 2013
223 / 234
SCALASCA
16 septembre 2013
224 / 234
TAU
Description TAU est un outil graphique danalyse de performances pour applications parallles. Principales caractristiques : Support de MPI et des applications multithreades/OpenMP Mode prolage ou prise de trace Nombre de processus illimit Support des compteurs hardware (via PAPI) Instrumentation automatique des boucles Suivi des allocations mmoire Suivi des I/O Arbre dappels Visualisation 3D (utile pour comparer les processus/threads entre-eux)
16 septembre 2013
225 / 234
TAU
16 septembre 2013
226 / 234
TotalView
Description TotalView est un outil de dbogage graphique dapplications parallles. Principales caractristiques : Support de MPI et des applications multithreades/OpenMP Support des langages C/C++ et Fortran95 Dbogueur mmoire intgr Nombre de processus maximum selon licence Utilisation Compiler votre application avec -g et un niveau doptimisation pas trop lev
16 septembre 2013
227 / 234
TotalView
16 septembre 2013
228 / 234
Travaux pratiques
16 septembre 2013
229 / 234
TP1 MPI HYDRO

Objectif Parallliser une application laide de MPI. Enonc On vous demande de partir de lapplication HYDRO version squentielle. Elle devra tre paralllise laide de MPI.
1
Dans un premier temps, la paralllisation peut se faire dans une seule direction (nord-sud en Fortran pour viter de passer par des types drivs). Ensuite, une version paralllise dans les 2 directions spatiales vous est demande.
Quelques conseils Les mailles servant imposer les conditions limites dans la version squentielle peuvent servir de mailles fantmes pour les communications entre processus. Une frontire entre domaines peut tre vue comme une condition limite particulire. Lutilisation dun communicateur de type topologie cartsienne est vivement conseill surtout pour la dcomposition 2D.
TP2 OpenMP Nid de boucles double dpendance
Objectif Parallliser le noyau de calcul suivant laide dOpenMP. ! Boucles avec double dependance do j = 2, ny do i = 2, nx V(i,j) =(V(i,j) + V(i-1,j) + V(i,j-1))/3 end do end do Enonc On vous demande de partir du noyau de calcul en version squentielle. Il devra tre paralllis laide dOpenMP.
1 2 3
En utilisant la mthode du pipeline. Optionnel : En utilisant la mthode des hyperplans Faites une courbe dextensibilit de votre/vos version(s) parallle(s).
16 septembre 2013
231 / 234
TP3 OpenMP HYDRO
Objectif Parallliser une application laide dOpenMP. Enonc On vous demande de partir de lapplication HYDRO version squentielle pour construire une version parallle OpenMP Fine-grain, mais avec une seule et unique rgion parallle.
16 septembre 2013
232 / 234
TP4 Hybride MPI et OpenMP Barrire de synchronisation
Objectif Synchroniser lensemble des threads OpenMP situs sur diffrents processus MPI. Enonc On vous demande de complter le chier barrier_hybride.f90 an que tous les threads OpenMP situs sur les diffrents processus MPI soient synchroniss lors dun appel au sous-programme barrierMPIOMP.
16 septembre 2013
233 / 234
TP5 Hybride MPI et OpenMP HYDRO
Objectif Parallliser une application laide de MPI et dOpenMP. Enonc

1
Intgrer les changements apports HYDRO dans les travaux pratiques prcdents an dobtenir une version hybride du code. Comparer les performances obtenues avec les diffrentes versions. Lextensibilit est-elle bonne ? Quelles amliorations peuvent tre apportes pour obtenir de meilleures performances ? Faites des essais et comparez.
16 septembre 2013
234 / 234

Form Hybride Proj

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Form Hybride Proj

Transféré par

Droits d'auteur :

Formats disponibles

Programmation hybride MPI-OpenMP

Version 1.10 16 septembre 2013

P.-Fr. Lavalle P. Wautelet (IDRIS)

Disponibilit et mise jour

P.-Fr. Lavalle P. Wautelet (IDRIS)

Recouvrement calculs-communications Types drivs

Etude de cas : HYDRO

Outils SCALASCA TAU TotalView

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

Consquences pour les utilisateurs

P.-Fr. Lavalle P. Wautelet (IDRIS)

Evolution des mthodes de programmation

P.-Fr. Lavalle P. Wautelet (IDRIS)

Turing : IBM Blue Gene/Q Ada : IBM x3750

P.-Fr. Lavalle P. Wautelet (IDRIS)

Chiffres importants Turing : 4 racks Blue Gene/Q :

Ada : 15 racks IBM x3750M4 :

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

Architecture Blue Gene/Q

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

Recouvrement calculs-communications Types drivs Equilibrage de charge Placement des processus

P.-Fr. Lavalle P. Wautelet (IDRIS)

MPI fournit galement les fonctionnalits suivantes (non exhaustif) :

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

voir http://meetings.mpi-forum.org/MPI_3.0_main_page.php https://svn.mpi-forum.org/trac/mpi-forum-web/wiki

P.-Fr. Lavalle P. Wautelet (IDRIS)

tat des implmentations actuelles

Remarque : la plupart des implmentations incluent une partie de la norme 3.0.

P.-Fr. Lavalle P. Wautelet (IDRIS)

Facteurs inuenant les performances MPI

P.-Fr. Lavalle P. Wautelet (IDRIS)

Facteurs inuenant les performances MPI

P.-Fr. Lavalle P. Wautelet (IDRIS)

Facteurs inuenant les performances MPI

P.-Fr. Lavalle P. Wautelet (IDRIS)

Types de communications MPI

P.-Fr. Lavalle P. Wautelet (IDRIS)

Modes denvoi point point

P.-Fr. Lavalle P. Wautelet (IDRIS)

Modes denvoi point point

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

P.-Fr. Lavalle P. Wautelet (IDRIS)

Envois en mode ready

P.-Fr. Lavalle P. Wautelet (IDRIS)

Modes denvoi point point

P.-Fr. Lavalle P. Wautelet (IDRIS)

Modes denvoi point point