H

1
Hétérogénéité des réseaux dans MPI défis et
perspectives

• Guillaume Mercier
• www-unix.mcs.anl.gov/mercierg

2
Plan de lexposé

• Problématique
• Deux archétypes
• PACX-MPI
• MPICH-G2
• MPICH-Madeleine
• Architecture
• Utilisation
• Performances
• Conclusion

3
Quelques repères

• Février Juillet 2000 Stage de DEA au LIP dans
  le projet INRIA ReMap (Loïc Prylli)
• Novembre 2000 Février 2002 Service National
  au Service Scientifique de lAmbassade de France
  à Tokyo
• Mars Août 2002 Début de thèse au LIP, dans le
  projet INRIA ReMap (Raymond Namyst)
• Septembre 2002 Février 2005 Suite et fin de
  thèse dans le projet INRIA RUNTIME à Bordeaux
• Mars 2005 Août 2006 Post-doctorat à lArgonne
  National Laboratory, dans léquipe de
  développement de MPICH2 (William Gropp et Ewing
  Lusk)
• Domaines de recherche
• Communications dans les architectures parallèles
• Supports dexécution hautes-performances
• Standard MPI

4
Contexte et problématique

• Il ny a pas si longtemps
• Grappes qui se répandent rapidement
• Multiples réseaux rapides disponibles
• Myrinet , SCI, VIA
• Popularisation des grilles de calcul
• Conséquences logiques
• Apparition des grappes de grappes
• Peut être vu comme un premier pas vers les
  grilles
• Volonté dadapter les outils existants
• Nombreux projets concernants MPI

5
Caractéristiques des grappes de grappes

• Interconnexion de grappes
• Architectures hiérarchiques
• Architectures hétérogènes

Communications inter-grappes
6
Pertinence du support multi-réseaux

• Grappes de grappes ?
• Pas si répandues que ça
• Objectif (peut-être ?) obsolète mais
  problématique toujours dactualité
• Systèmes multirails homogènes ou hétérogènes
• Grappes multiplement câblées
• Ex IBM BG/L 1 au Top 500, réseaux Tree et Torus
  
• Grilles de calcul

7
Premier exemple PACX-MPI

• Surcouche logicielle
• Transparente pour lapplication
• Passerelles pour les communications
  inter-grappes
• Goulot détranglement potentiel
• Communications inter-grappes basées sur TCP/IP
  uniquement
• Deux noeuds (au moins) ne participent pas au
  calcul

8
Second exemple MPICH-G2

• Basé sur MPICH et Globus
• Vise les grilles de calcul
• Lensemble des noeuds sont connectés
• Communications inter-grappes basées sur TCP/IP
• Opérations collectives optimisées, exploitant la
  topologie

9
Caractéristiques communes

• Schéma de type inter-opérable
• Plusieurs implémentations de MPI communicantes
• Illustration du MPI Paradox
• Communications intra-grappes avec un MPI local
  (optimisé)
• Communications inter-grappes basées sur TCP
  (optimisé ?)
• Liens rapides inter-grappes inexploités
• Passerelles inexploitées
• Pas vraiment multi-réseaux !
• Exemple typique la gestion des grappes
  multiplement câblées
• Les vendors MPI sous-jacent doivent posséder la
  propriété

10
Objectifs et hypothèses

• Objectifs
• Exploitation optimale du matérial sous-jacent
• Maîtrise au niveau applicatif de la configuration
  matérielle
• Lintelligence est au niveau du programmeur, pas
  du middleware
• On ninterdit pas au logiciel de prendre des
  décisions
• On veut quelque chose de user-friendly
• Hypothèses
• Echelle concernée les grappes de grappes
• Pas de problèmes
• De réservation de ressources
• De déploiement
• Dauthentification et de sécurité

11
MPICH-Madeleine

• Approche originale
• Pile unifiée (logiciel Stand-alone )
• Approche originale à lépoque, reprise par VMI
  notamment
• Moteur de progression multithreadé
• Essais précédents échecs ( sauf MPI/Pro ?)
• Moteur partiellement multithreadé (SCI-MPICH,
  Open MPI)
• Une déclinaison de MPI supportant des
  configurations complexes
• Exploitation des réseaux rapides intra-grappes
• Exploitation des passerelles et liens haut-débit
  inter-grappes
• Une implémentation de MPI efficace sur les
  configurations multi-protocoles
• Grappes homogènes de machines multi-processeurs
• Grappes de grappes hétérogènes
• Grilles exclues du champ de létude (a priori, cf
  hypothèses)

12
Architecture de MPICH-Madeleine
MARCEL Bibliothèque de Processus légers
13
Architecture de MPICH-Madeleine

• Architecture modulaire

14
Principes architecturaux

• Utilisation de processus légers
• Implantation dun moteur de progression des
  communications
• Gestion multi-protocole
• Simplifiée
• Extensible
• Utilisation dune interface générique de
  communication
• Interface opaque
• Exploitation efficace des réseaux sous-jacents
• Gestion à bas niveau de services pour la gestion
  des grappes de grappes (passerelles, routage)

15
Avantages du multithreading

• Unification des mécanismes de scrutation
• Portabilité
• communications motorisées sur tout type de
  matériel
• Extensible
• Rajout simple de nouveaux protocoles
• Amélioration de la progression des
  communications
• Appels non-bloquants asynchrones
• Recouvrement calcul/communication
• Progression découplée des communications et de
  lapplication
• Utilisation des processus légers au niveau
  applicatif
• MPI_THREAD_MULTIPLE supporté

16
La bibliothèque Madeleine

• Une bibliothèque de communication
  haute-performance
• Sous-système de communication de PM2
• Interface orientée Passage de Messages
• Construction incrémentale des messages
• Interface restreinte
• Propriétés intéressantes
• Utilisation en environnement multithread
• Sélection dynamique de la meilleure méthode de
  transfert
• Support des grappes de grappes (routage,
  retransmission)
• Objets de base pour les communications les
  canaux
• Un ensemble de connexions
• Similaire à un communicateur MPI

17
Les canaux dans Madeleine

• Deux grandes familles de canaux
• Les canaux physiques
• Les canaux virtuels
• uniquement construits à partir de canaux
  physiques
• Création de réseaux virtuels hétérogènes
• Exploitation des passerelles
• Manipulation avec des fichiers de configuration
• Flexibilité
• Changement de réseau sans recompilation

18
Support multi-protocole

• Un processus léger est associé à chaque canal de
  communication
• Bonus utilisation des processus légers au
  niveau applicatif
• Cas particulier le canal default
• Un canal est associé à un communicateur
• Manipulation de la topologie au niveau applicatif
• Interface réduite
• MPI_COMM_NUMBER nombre de canaux disponibles
• MPI_USER_COMi Communicateur associé au canal
  i
• MPI_GetCommFromName Accès au communicateur par
  son nom de canal
• Interface optionnelle
• Uniquement pour tirer parti de la topologie
  sous-jacente
• Portabilité préservée
• Pas de modification de la sémantique MPI pour les
  communicateurs
• Tous les programmes existants peuvent utiliser
  MPICH-Madeleine sans modifications
• MPI_GetCommFromName implémenté avec des appels de
  la bibliothèque MPI
• Utiliser les attributes ?

19
Utilisation de MPICH/Madeleine

• Lintégralité des informations est donnée à MPI
  avec des fichiers de configuration
• Un premier fichier contient la disposition
  physique des réseaux (correspondance
  machine/réseaux)
• Fichier écrit une fois pour toute à
  linstallation (et en cas de modification
  physique de la grappe)
• Un second fichier contient la correspondance
  canaux/réseaux
• Fichier différent pour chaque lancement

20
Utilisation de MPICH/Madeleine

• Exemple de configuration
• 2 nœuds avec SCI
• 2 noeuds avec GM/Myrinet
• GigabitEthernet entre les deux grappes

21
Le Fichier de Réseaux

• networks (
• name tcp_net
• hosts (node0,node1,node2,node3)
• dev tcp
• ,
• name sci_net
• hosts (node0,node1)
• dev sisci
• ,
• name gm_net
• hosts (node2,node3)
• dev gm
• )

22
Le Fichier de Canaux

• channels (
• name my_sci
• net sci_net
• hosts (node0,node1)
• ,
• name my_gm
• net gm_net
• hosts (node2,node3)
• ,
• name my_tcp
• net tcp_net
• hosts (node0,node1,node2,n
  ode3)
• )
• vchannels
• name default
• channels
  (my_sci,my_gm,my_tcp)

23
Construction des Canaux

• Changement de réseaux sans recompilation
• Doit être compilé avec le support pour tous les
  réseaux
• Plusieurs canaux physiques peuvent être déclarés
  au-dessus du même réseau
• Un canal virtuel consume les canaux physiques
  sur lesquels il est construit
• Lapplication ne peut plus y accéder
• Important ordre de déclaration ordre de
  priorité

24
Comparaison avec MPICH-G2

• Environnement de tests
• Une grappe SCI connectée à une grappe Myrinet
• Communications inter-grappes directes
• MPICH-Madeleine est utilisé comme Vendor MPI
  pour MPICH-G2
• Comparaison des mécanismes inter-grappes de G2
  avec les canaux virtuels de Madeleine

25
Pourquoi MPICH-Madeleine en tant que Vendor MPI ?
26
Comparaison avec MPICH-G2 résultats
27
Comparaison avec MPICH-G2 conclusion

• Les résultats dépendent des Vendor MPI
• Lintégration de MPICH-Madeleine élimine le biais
  
• Comparaison entre Pile Unifiée et Approche
  Inter-Opérable
• Avantage à la pile unifiée
• Mais micro-benchmarks
• Mais contexte faible distance (grappes de
  grappes)

28
Comparaison avec PACX-MPI

• Environnement de tests
• Deux grappes SCI connectées
• Passerelles GigaBit Ethernet, Myrinet, directe
  SCI-SCI
• Communications inter-grappes avec
  retransmissions
• Comparaison des passerelles de PACX-MPI avec
  celles de Madeleine

29
Comparaison avec PACX-MPI résultats
30
Comparaison avec PACX-MPI conclusion

• 1 passerelle vaut mieux que 2 (évident)
• Goulot détranglement utilisation de TCP
• PACX-MPI et MPICH-Mad ont des résultats
  similaires
• MPICH-Mad peut utiliser dautres protocoles
• TCP testé version standard
• Et avec une version optimisée ?
• Quelles contraintes liées à la longue distance ?
• Test de type micro-benchmark (ping-pong)
• Tests en situation réelle ?
• Quelles applis prendre ?

31
High-Performance Linpack
HPL sur deux nœuds bi-pro avec HyperThreading
32
High-Performance Linpack (2)
HPL sur deux nœuds bi-pro sans HyperThreading
33
High-Performance Linpack (3)
HPL sur quatre nœuds bi-pro avec HyperThreading
34
Progression indépendante des communications

• Exemple anneau de processus
• Appels non-bloquants Isend
• Cas du protocole rendez-vous

Implémentation non-bloquante et non-asynchrone
MPICH-Madeleine
35
Résultats

• Anneau de huits processus
• Message de 2 Ko (eager) et 1 Mo (rendez-vous)

Version de MPI Temps total (eager) Temps total (rendez-vous)
MPICH-GM 11,5 sec 130,8 sec
MPICH-Madeleine/GM 11,8 sec 19,2 sec
Version de MPI Temps total (eager) Temps total (rendez-vous)
MPICH-P4 5,6 sec 45,5 sec
MPICH-Madeleine/TCP 8,1 sec 9,5 sec
36
Conclusion

• Comparaison facile entre pile unifiée et
  interopérable
• Architectures et implémentations différentes,
  comparables
• Pas de comparaisons entre modèles
• Passerelles vs Fully connected
• Trop de biais possibles
• Manque doutils
• MPICH-Mad supporte les deux modèles
• MetaMPICH aussi (depuis peu)
• Pas détudes sur le sujet
• Trop dépendant du couple (application,
  architecture matérielle)
• A sa place dans un cadre longue distance

37
Pespectives Support des grilles dans
MPICH-Madeleine

• Grilles a priori exclues du champ de létude
• La gestion du multi-réseau indépendante de
  léchelle
• MPICH-Madeleine applatit la hiérarchie
• Stratégie valable pour grappes de grappes
• Stratégie non-viable pour les grilles
• Options
• Utiliser MPICH-Madeleine dans un environnement
  plus large
• Portage dans MPICH-G2 déjà opérationnel
• Outils pour Grid5000
• Adapter MPICH-Madeleine
• Point a revoir articulation SAN/WAN
• Etudier les modèles de programmation
• Revoir le déploiement par rapport a la topologie

38
Plans for the Next Year

• Full MPI-2 compliance
• Add external32 data representation
• Thread safety
• Thread safety is relatively easy safety and
  performance is not
• Explore how to do this efficiently with
  fine-grained locks, rather than locking the
  entire progress engine on entry
• Collective communication
• Currently optimized for flat network topologies
• Recent work this summer looked at multiple
  concurrent communication channels (available on
  IBM BG/L)
• Optimize for hierarchical network topologies,
  such as clusters of SMPs and the TeraGrid
• One-sided communication
• Synchronization functions already optimized, but
  data transfer uses two-sided semantics at lowest
  levels
• Extend low-level APIs and implementation to allow
  true RDMA
• Replacement Basic Communication Device

39
New Communication Core Nemesis

• Provide an infrastructure to answer basic
  questions about scaling MPI implementations
• What is the overhead of MPI?
• Typically, one measures some MPI implementation,
  then claims that is the overhead of MPI confuses
  an implementation with a specification
• Our goal Develop a fast, well-instrumented and
  analyzed communication core
• Answer questions about overhead, cost of MPI
• Provide higher-performance, lower-latency open MPI

40
New MPICH2 Communication Device

• Current work is developing a channel for the
  ch3 device
• Key Features
• Shared memory is considered as first-class
  citizen
• Lock-free queues
• Low latency
• Extremely scalable
• Multi-method
• New networks are easy to add
• 5 required functions
• init, finalize, direct_send, poll_send, poll_recv
• Optional functions for RMA and collectives for
  enhanced performance
• Follows standard MPICH approach that allows
  easier initial ports, followed by performance
  tuning

41
Basic Design

• A new MPICH2 channel implementation
• Shared memory considered as first-class
  citizen
• Network communication goes through shared
  memory, rather than the other way around
• Natively Multi-method

42
Basic Design

• Each process features several queues in shared
  memory that handle most of the communication
• One Free Queue
• One Recv Queue
• Each process also features a pair of Fast
  Boxes for each destination process
• Used for small messages
• Best achievable latency
• Lowest Instruction count
• Plus Network Modules for non-shared memory
  communication
• Use Processes Free and Recv Queues

43
Lock-Free Queues

• Low latency
• No locks
• Uses compare-and-swap and swap atomic
  instructions
• Simple implementation
• Enqueue 6 instructions, 1 L2 cache miss
• Dequeue 11 instructions, 1-2 L2 cache misses
• Progress engine has only one queue to poll
• Extremely scalable
• Each process needs two queues regardless of the
  number of processes
• Recv queue
• Free queue
• Progress engine has only one queue to poll
• Same queue mechanism is used for networks
• Messages received from networks are enqueued on
  the recv queue

44
Network Modules and Shared Queues
Process
Process
Lock-free Queues
45
Multi-method Receive

• Network module receives a message and queues it
  on the recv queue
• Where does the network module get the queue
  entry?
• The entry must be in shared memory because other
  SMP processes need to enqueue behind it
• Each network module has its own free queue
• How do we avoid memcopies?
• Register all queue entries
• Network needs to be able to register shared
  memory
• No data needs to be copied simply enqueue the
  received packet

46
Multiple Network Multi-method Issues

• In order to be able to have networks send and
  receive directly from/into queue elements, they
  need to be registered by each network
• Can multiple networks register the same memory
  region? (probably not)
• Solution
• Only one network will be able to register
• Others will have to copy
• Motivation
• Theres probably only one high-speed local
  network
• Inter-cluster networks can afford an extra copy

47
Multiple Networks
48
Performances sur processeurs 32-bits

• Communications utilisant la mémoire partagée
• Processeurs Intel Pentium 4 Xeon, 2 GHz
• Programme de test Netpipe
• Latence minimale 0,68 µs
• Débit maximal 650 Mo/s

49
Performances sur processeurs 64-bits

• Communications utilisant la mémoire partagée
• Processeurs AMD Opteron 280, 2,4 GHz, dual core
• Programme de test Netpipe
• Latence minimale 0,34 µs
• Débit maximal 1,37 Go/s

50
Performances sur processeurs 32-bits

• Communications utilisant Myrinet/GM
• Processeurs Intel Pentium 4 Xeon, 2 GHz
• Programme de test Netpipe

51
Performances sur processeurs 32-bits

• Communications utilisant TCP/GigaBit Ethernet
• Processeurs Intel Pentium 4 Xeon, 2 GHz
• Programme de test Netpipe