Multithreading et Calcul Haute Performance
description
Transcript of Multithreading et Calcul Haute Performance
Multithreading et Calcul Haute Performance
J-F. Méhaut, R. NamystINRIA, ReMaP, LIP, ENS Lyon
Au menu
Introduction : contexte technologique Nouvelles archis: processeurs, réseaux, etc.
Multithreading : quels intérêts? Définition, premiers contacts, partage
mémoire Pause (10’) Multithreading distribué
Intérêts et difficultés Quelques environnements L’environnement PM2
Conclusion
Introduction
Architecture processeur Cray-TERA
3 41 2Applications
Threads concurrents
Streams
i=1 i=2
i=3 i=n…
j=1
…
j=2
j=3 j=m
G(A)F (a)
F (b)Programme
séquentiel
Pool d’instructions prêtes
Pipeline d’instructions en cours d’exécution
Multi-threading Cray-TERA
Principe Maintenir plusieurs threads (streams) actifs
(40 à 80 streams => 90% utilisation de la machine)
Garantir une instruction prête à chaque cycle processeur
Dispositif matériel supportant Gestion de plusieurs streams Changement de contexte tous les cycles (3ns) Jusqu’à 8 requêtes d’accès mémoire en attente
pour un stream
Caractéristiques du processeur Cray-TERA
Horloge 333 MHZ
Accès mémoire 2,8 Gbytes/seconde bande passante Emission/réception d’un paquet par cycle Pas de cache de données, cache instr 2Mbytes
Multiprogrammation/concurrence 16 domaines de protection 128 streams (32 registres, 1 Program Counter)
Enjeux
Trouver le bon niveau de parallélisme Besoin de travail (threads) pour saturer
la machine Quatre sources potentielles de
parallélisme Applications (jobs) Threads Boucles ILP (Instruction-Level Parallelism)
Compilateur/paralléliseur Marché restreint
Une machine installée à San Diego
Cluster computing
Architecture homogène, faiblement hétérogène Grappes (Cluster, COW), machines //
PC, stations de travail SCI, Myrinet, Giganet, MPC, ...
Protocoles de communication BIP, SISCI, SciOS, VIA, TCP, UDP, ...
Myrinet/BIP
PC
Commutateur
Motivations pour le haut-débit
Performances des communicationsAtteindre le niveau de performance des machines
parallèlesavec les équipements du marché (PC ou station de
travail)
Minimiser la latence, maximiser le débit
Thématiques de recherche Matériel
Commutateurs, cartes d’interface Commutations, routage
Logiciel Interfaces de communication (AM, FM, BIP, …) Env. de programmation (MPI, PM2, Nexus,…)
Myrinet
Objectifs Performances en communication
équivalentes à celles des supercomputers Quelques microsecondes en latence Atteindre le Gbps en bande passante
Caractéristiques Carte d’interface programmable Protocole : carte d’interface et le host Utilisé pour implémenter des
environnements de programmation
Myrinet : Description technique
Myrinet commutateur
HostCarte d’interface
HostCarte d’interface
Myrinet commutateur
HostCarte d’interface
HostCarte d’interface
Host
Carte d’interface
Host
Carte d’interface
Câble 2,6 Gbps full duplex
Crossbar complet
Routage Statique à la source (entête consommé
progressivement) Wormhole
Myrinet : cartes d’interface
Matériel 66MHz cpu (LANai) 1 Mbyte SRAM 3 DMA (lien entrée, lien sortie, mémoire du
host) Interface au bus PCI
Logiciel LANai Control Program (LCP)
Lien MyrinetRISC
Packet
Interface
DMA
Controler
DMA
Controler
PCI
Bridge
PCI
Bridge
PCI Bus
LANai
MemoryMemory
Performance (BIP/Myrinet) 6 microsecondes latence 127 Mbytes/sec bande passante
SCI*(Scalable Coherent Interface)
Interconnexion SCI
Processus A
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Processus B
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Mémoire physique
Réseau à capacité d’adressage Adressage des mémoires distantes Lecture/écriture distante sans interruption du processeur
distant Support matériel pour mémoire partagée
* Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)
SCI : caractéristiques techniques
Scalable Coherent Interface Matériel standard (PC, station Unix, …) Architecture en anneau et/ou commutateur Evolutif jusqu’à 64 Knœuds Bande passante de 500 Mo/s (4 Gb/s) full-duplex
Pas de cohérence sur PCI (bus d’entrées/sorties)
Latence Cache L1
Cache L2
Mémoire SCI
Lecture 5 ns 60 ns 120 ns 4 µs
Ecriture 5 ns 60 ns 120 ns 2 µs
* Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)
SCI : performances
Latence : 2.5 s (écriture de processus à processus) Débit :70 Mo/s Verrou : < 10 s (fetch&add)
Comms : remarques préliminaires
Règle des 80/80 80% des messages sont de taille inférieure à 256
octets 80% du trafic provient de messages d’une taille
supérieure à 8KB
Nouvelles approches Latence faible pour les petits messages Bande passante importante pour les gros messages Coût des protocoles traditionnels
Communications système
Evolutions technologiques Coûts logiciels des protocoles
Protocole système (TCP/UDP/IP)
Réseaux 10 Mb
Réseaux 100 MbRéseaux Gb
Comm. en contexte utilisateur
Processus
Interface
OS
Recherches académiques Active Messages (Berkeley) Illinois Fast Messages (Urbana) U-Net (Cornell) MPC (Paris6, Versailles) BIP (Lyon)
Interface de bas-niveau Cibles pour les supports d’exécution
Standard industriel : VIA Participation des industriels Etendre le spectre des applications
VIA : Virtual Interface Architecture
VI Consumer
VI User Agent (“libvia”)
Ope
n, C
onne
ct,
Map
Mem
ory
Descriptor Read, Write
VI-Capable NIC
Sockets, MPI,Legacy, etc.
RequestsCompleted
VI VI C
S S S COMP
R R R
VI
Do
orb
ells
Und
eter
min
ed
VI Kernel Agent (Slow) User-Level (Fast)
Host
NIC
Giganet : Cartes VIAGiganet : Cartes VIA
TCP/IPTCP/IP
Winsock APIWinsock APIWinsock APIWinsock API
FastFast
NDISNDIS
VI APIVI API
FastestFastest
ApplicationApplicationApplicationApplication
Native VI InterfaceNative VI Interface
With VIA50 versus 7000
instructions
™
• Commutateurs• Cartes d’interface• Administration du réseau• cLAN pour Windows• cLAN pour Linux
Supports d’exécution parallèle
Avantages pour les utilisateurs Abstractions de haut niveau Portabilité des applications Efficacité !
Support d’exécution //
Architectures parallèles et distribuées
Systèmes d’exploitation
Interface de programmation (API)
Applications
Le multithreading :quel(s) intérêt(s) ?
Introduction et rappels
Rappel : les processus lourds
Caractéristiques Entité active directement supportée par
l’OS Flot d’exécution Espace d’adressage privé Ressources systèmes
Exécution séquentielle Coût de gestion élevé
Allocation des ressources Appels systèmes
Processus lourds (bis)
Ressources “kernel” + données “user”
processeur processeur processeur
Noyau
Processus
Ordonnanceur
Espace utilisateur
Processus Processus
Threads : Motivations
Difficulté de programmation Fil d’exécution unique
une seule chose à la fois !
Partage de données laborieux
Performances Opérations de base coûteuses Recouvrement des opérations d’E/S
difficiles
Simplicité de programmation
Objectif Mener plusieurs activités indépendantes
au sein d’un processus Exemples
Simulations Serveurs de fichiers Systèmes d’exploitation (!)
Seule solution (?) Automate à états finis implanté « à la
main »(sauvegardes d’états)
Structure d’un OS monolytique
Exemple
Séquence infinie d’opérations courtes Ordre et fréquence des scrutations ?
for (;;) {
if(networkMsgIn()) getNetworkMsg();
if(kbdReady()) getKey();
if(diskBlockReady()) handleDiskBlock();
…
}
Systèmes multiprogrammés
Exécution indépendante des activités Concurrence entre les différents
traitements
for (;;) {
wait for network msg;
getNetworkMsg();
}
for (;;) {
wait for key stroke;
getKey();
}
for (;;) {
wait for disk block;
handleDiskBlock();
}
Processus serveur classique
Sérialisation des requêtes
Pas de recouvrement des E/S Exploitation SMP délicate Prise en compte de priorités ?
OS OS
client serveur
Sur l’efficacité des E/S
Caractéristiques du serveur de fichiers Tps de traitement d’une requête = 15ms Tps supplémentaire pour l’accès disque =
75ms (pour 1/3 des requêtes)
Débit sans/avec recouvrement des E/S Sans recouvrement
25 requêtes/seconde
Avec recouvrement 33.33 requêtes/seconde (+33%)
Les processus légers
Principe Détacher flot d’exécution et ressources
Introduits dans divers langages & systèmes Programmation concurrente Recouvrement des E/S Exploitation des architectures SMP
thread
ressources
Caractéristiques de base
Thread = pile + contexte Partage de ressources
Code, tas, … : espace d’adressage Fichiers ouverts Table des traitants de signaux
Opérations de base performantes Création, destruction Synchronisation, commutation de contextes
Création d’un processus léger Adresse de fonction à exécuter +
paramètres
Performance des threads
Opérations critiques Création/destruction (gestion mémoire) Changement de contexte (temps-
partagé) Synchronisation (mode utilisateur)
Programme d’évaluation Création d’une activité (processus,
thread)+ synchronisation (terminaison de l’activité)
OS/Processeur Processus
Thread noyau
Thread utilisateur
PM2
Linux 2.2/PII 450 0.540 0.130 - 0.006
Solaris 2.7/PII 350
8.622 0.214 0.160 0.009
Repères historiques
L’ancêtre : les coroutines Entrelacement explicite des exécutions Langages : Simula (67), Modula2 (82) Primitives clés : create + resume
Les threads dans les systèmes Cthread (Mach) -> DecThread -> PThread
(~90) Chorus, Solaris (87), winNT, IRIX, Linux, etc.
Les threads dans les langages Ada (83), Java, etc. C++ //, Eiffel //, etc.
Le multithreading :quel(s) intérêt(s) ?
Premier contact
L’interface POSIX-Threads
Interface de programmation standard pour Unix Portabilité des applications Solaris, IRIX, HP-UX, Linux, etc.
Fonctionnalités Création/destruction de threads Synchronisation Ordonnancement, priorités Signaux Etc.
Exemple: création
Création d’un nouveau thread Éventuels attributs dans la structure attr Exécution de start_func avec le paramètre
arg *pid est l’identificateur du thread créé
int pthread_create( pthread_t *pid,
pthread_attr_t *attr,
void * (*start_func)(void *),
void *arg);
Attente de fin d’exécution
Attente de la terminaison du thread pid Récupération de son code de retour
status On peut contourner ce mécanisme en
« détachant » les threads :
int pthread_join( pthread_t pid,
void **status);
int pthread_detach( pthread_t pid);
« Hello World! »
#include <stdio.h>#include <pthread.h>
void *func(void *arg){
printf(“Thread %x says %s\n”, pthread_self(), arg);return NULL;
}
int main(void){
pthread_t pid;
pthread_create(&pid, NULL, func, “Hello World!”);printf(“This is the main thread\n”);pthread_join(pid, NULL);return 0;
}
Attributs
Ensemble fixé de caractéristiques Utilisé à l’initialisation Threads, verrous, variables de condition,
etc. Threads
Priorité Pile : taille, emplacement Détaché : oui/non Type d’ordonnancement
Verrous Inversion de priorités, récursivité
Attributs : exemple
#include <stdio.h>#include <pthread.h>
void *handle_request(void *arg){
…}
int main(void){ …
pthread_attr_t attr;
for(;;) {fd = accept(sock, …);pthread_attr_init(&attr);pthread_attr_setdetachstate(&attr,
PTHREAD_CREATE_DETACHED);pthread_create(NULL, &attr, handle_request, fd);
}}
Exemple bis : pile
À manipuler avec précaution ! Quelle taille de pile choisir ? Comment prévenir/détecter les
débordements ?
pthread_attr_t attr;
pthread_attr_init(&attr);pthread_attr_setstacksize(&attr, 128*1024);pthread_create(NULL, &attr, func, NULL);
Le standard OpenMP
Interface pour écrire des applications multithreads portables (sur SMP) Directives de compilation (C, C++, Fortran)
+ routines Objectif = simplicité + portabilité Constructeurs + fabricants de logiciels +
etc. Modèle de programmation
« Fork-Join » Parallélisation des boucles (#pragma omp)
Le multithreading :quel(s) intérêt(s) ?
Partage mémoire efficace
Les threads et la mémoire
Chaque thread possède sa propre pile Variables locales « privées » ( visibilité)
Les threads partagent l’espace d’adressage Variables globales Tas (malloc) Variables locales (piles) également !
Intérêt Communications par pointeurs ! Parallélisation de programmes séquentiels
aisée ?
Problèmes de réentrance
Exemple simple :int glob = 0;
void *inc(void *arg){ int i;
for(i=0; i<100; i++)glob++;
}
int main(void){
pthread_create(&t1, NULL, inc, NULL);pthread_create(&t2, NULL, inc, NULL);
pthread_join(t1, NULL); pthread_join(t2, NULL);printf(“glob = %d\n”, glob);
}
Résultat ?
Explication
glob++ n’est pas forcément une opération atomique
Scénario d’exécution concurrente par 2 threads :
Mov @glob, $r1 ; chargerInc r1 ; incrémenterMov $r1, @glob ; enregistrer
Mov @glob, $r1Inc r1
Mov @glob, $r1Inc r1Mov $r1, @glob…
Mov $r1, @glob
Mov @glob, $r1Inc r1
Mov @glob, $r1Inc r1Mov $r1, @glob…
Mov $r1, @glob
Outils pour la synchronisation
Exclusion mutuelle : les verrous
Synchronisations plus complexes : Variables de condition (cf moniteurs de
Hoare) pthread_cond_wait pthread_cond_signal, pthread_cond_bcast
int glob = 0;
void *inc(void *arg){
for(i=0; i<100; i++) {pthread_mutex_lock(&mutex);glob++;pthread_mutex_unlock(&mutex);
}}
Code réentrant
« code demeurant correct lorsqu’il estexécuté simultanément par plusieurs
threads » Exemples typiques
Fonction n’utilisant que des variables locales Code protégé par un verrou
Quid du code que l’on écrit pas soi-même ? Malloc, free, …, la bibliothéque standard Fonctions « MT-safe »
Option –D_REENTRANT Certains prototypes changent…
Importance de la synchro.
Cohérence séquentielle de la mémoire ? Compilateurs/Optimiseurs
Instructions réordonnées
Processeurs modernes Ecritures réordonnées
On ne peut pas supposer l’ordre des écritures
Primitives de synchronisation Agissent comme des « barrières
mémoire »
Variables spécifiques
Pb : comment gérer les variables globales « privées »
int my_x;
void g(void){
…my_x…}
void f(void){
my_x = do_compute();…g();
}
Variables spécifiques
Principe Variable accessible à partir d’une clé Allocation globale (souvent à l’initialisation)
pthread_setspecific(clé, valeur) pthread_getspecific(clé) -> valeur
Exemple : la variable errno Fichier errno.h
#ifdef _REENTRANT#define errno (*__errno_location())
#elseextern int errno;
#endif
A propos d’efficacité
Les threads sont-ils toujours meilleurs que MPI sur architectures SMP ?
Solution « processus communicants » Communications pénalisantes (copies) Surcoût en utilisation de ressources Recouvrement plus difficile
Solution « processus légers » Synchronisations additionnelles Accès aux variables spécifiques coûteux
Le multithreading :quel(s) intérêt(s) ?
Ordonnancement des threads
Multithreading utilisateur
Deux ordonnanceurs indépendants :
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Scheduler Scheduler
Multithreading noyau
Un seul ordonnanceur :
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Multithreading mixte
Deux ordonnanceurs coopérants
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Scheduler Scheduler
Note: Quid des appels systèmes bloquants ?
Ordonnancement non-préemptif
Le processus cède la main Lorsqu’il se bloque Lorsqu’il meurt
Avantages Peu de commutations de contextes Atténuation des problèmes de
réentrance Inconvénients
Partage non-équitable des ressources Risque de famines
Ordonnancement préemptif
Une horloge force les commutations Avantages
cf. inconvénients du non-préemptif Inconvénients
cf. avantages du non-préemptif En général
Threads noyaux préemptif Threads utilisateurs non-préemptif
Choix de l’ordonnancement
Niveau d’ordonnancement pthread_attr_setscope(…)
PTHREAD_SCOPE_SYSTEM PTHREAD_SCOPE_PROCESS
Classes d’ordonnancement pthread_attr_setschedpolicy(…)
SCHED_FIFO SCHED_RR SCHED_OTHER
Le multithreading :quel(s) intérêt(s) ?
Recouvrement des Entrées/Sorties
Recouvrement des E/S
Au lieu de
Espace noyau
Espace utilisateur
Matériel
syscall
…on voudrait :
Espace noyau
Espace utilisateur
Matériel
I/O request interrupt
Temps CPU perdu
CPU utilisé
E/S et ordonnancement
Threads noyaux : OK Threads utilisateurs
Appel bloquant -> blocage du processus entier
Threads mixtes Idem au bout d’un certain nombre !
Solutions ? Appels toujours non-bloquants (polling) Appels effectués par des threads dédiés Support système spécifique
Scheduler Activations
Introduit par [Anderson et al. 91] Idée: la coopération entre les deux
ordonnanceurs est bidirectionnelle L’ordonnanceur utilisateur utilise des appels
systèmes L’ordonnanceur noyau utilise des upcalls!
Upcalls Informe l’application des événements noyaux
Activations Autant d’activations en exécution que de
processeurs Contrôlées par le noyau
Principe mis en œuvre dans Solaris
MultithreadingDistribué
Principe et Enjeux
Principe
Introduire les threads dans les applications distribuées
procproc proc proc
réseau
Enjeux
« Bénéfices » escomptés Recouvrement naturel des communications Meilleur support du parallélisme à grain fin Uniformisation de la configuration
machines monoprocesseur/machines SMP Virtualisation de l’architecture
threads = processeurs virtuels cible pour des compilateurs (ex: HPF) équilibrage de charge générique et transparent
Meilleure réactivité au réseau Exécution distribuée de langages
multithreads
Virtualisation
Objectif Machine constituée de centaines de
processeurs virtuels Intérêts
Applications s’adaptant à la configuration Passage à l’échelle (scalability) Équilibrage de charge possible par
migration de threads Équilibrage dynamique Régulateur indépendant de l’application !
Virtualisation : contraintes
Exécution indépendante à la localisation Problème des E/S délicat
Communications par mémoire partagée Mémoire virtuellement partagée nécessaire
Compatible avec les threads ! Difficile sur architecture hétérogène
Architecture hétérogène Migration des threads prohibitive
Meilleure réactivité au réseau
Illustration : MPI et les communications asynchrones
Processus A Processus B
Acquittement
MPI_Isend
MPI_recv
MPI_test
MultithreadingDistribué
Quel modèle de programmation ?
Approche par juxtaposition
Principe : pas de modèle ! Simplement utiliser conjointement
Une bibliothèque de communication (ex: MPI) Une bibliothèque de multithreading
Problèmes Conceptuels
Pas de visibilité globale des threads Sémantique des communications ?
Techniques Compatibilité entre les bibliothèques Travail d’intégration spécifique -> non
réutilisable
Threads communicants
Principe Envoi de message entre threads
Modèle « MPI-like » Modèle « Acteurs »
Nommage Nommage global des threads Ports de communication
Exemples Chant (M. Haines, ICASE) Athapascan-0b (J. Briat, INRIA Grenoble)
Modèle Pthreads étendu
Principe Threads + primitives étendues
Create/Join à distance Synchronisations distribuées
Particularités Nommage global des threads Restriction du modèle Pthreads
Exemples Chant (M.Haines, ICASE),
Rthreads (M. Zahn, Allemagne)
Modèle Pthreads distribué
Principe Adaptation complète (?) de Pthreads
Threads + mémoire virtuellement partagée
Transparence Cohérence assurée lors des défauts de
pages Restriction sur les E/S
Extensions Cohérences mémoires relâchées
Exemple DSM-Threads (F. Mueller, Berlin)
Modèle dérivé des RPC
Principe Appel de procédure à distance (A. Birell)
Extension du concept aux threads Création de threads pour exécuter les
procédures
Désignation globale des services Numéro fonction Souches (stubs) pour la transmission des
paramètres
Exemples Nexus (I. Foster, Argonne), PM2
MultithreadingDistribué
Intégration des threadset des communications
Progression des communications
Problème Comment assurer la progression des
communications ?
procproc proc proc
réseau
Scrutation et interruptions
La scrutation est nécessaire API réseau ne fournissant pas d’appels
bloquants OS ne fournissant pas “d’activations”
Problème Fréquence difficile à assurer Coûteux en présence de multiple “pollers ”
Les interruptions sont nécessaires Réactivité
Problème Outils de synchronisation “interrupt safe” ?
Scrutation par l’ordonnanceur
Ordonnanceurdes threads
Création d’une catégoriede polling (ex: MPI), assignation d’une fréquence et enregistrement de callbacks.
Polling jobsqueue
MPI
MPI_IsendMarcel_poll
Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque.
MPI_IrecvMarcel_poll
callbackcallback
Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur...
Polling( )
MultithreadingDistribué
L’environnement PM2
Premières réflexions sur PM2
Parallel Multithreaded Machine (R. Namyst) Virtualisation de l’architecture Régulateurs génériques de charge (Y. Denneulin) Plateformes usuelles (COW, NOW), machines
parallèles Distribution du logiciel, assistance, documentation:-(
InterPRC Stratagème (C. Roucairol) Applications irrégulières
Optimisation combinatoire Algèbre linéaire creuse (J. Roman)
Ordonnancement, régulation Fortement irrégulière : placement + migration
Projet PM2 (95-xx)
Objectif ambitieux : virtualisation Indépendance de la machine cible
(#processeurs) Degré de parallélisme important (#processus) Parler de “traitement” / “processus”
mécanismes de décomposition parallèle
Propositions Mécanisme de décomposition
Appel de procédure à distance léger (LRPC)
Support des activités Processus légers (threads)
Régulateur dynamique de charge Placement + Migration
Appel de procédure à distance
Différentes déclinaisons Synchrone Attente différée Asynchrone
PM2 PM2
LRPC
Nos concurrents... Nexus : RSR Athapascan : appels de service
Hello World!#include <pm2.h>unsigned SAMPLE;void sample_func(void){ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);pm2_rawrpc_waitdata();printf(“%s\n”, msg);
}void main(int argc, char **argv){ int module[MAX_MODULES], nb_modules;
pm2_rawrpc_register(&SAMPLE, sample_func);pm2_init(&argc, argv, 2, module, &nb_modules);if(pm2_self() == les_modules[0]) {
pm2_rawrpc_begin(module[1], SAMPLE, NULL);pm2_pack_byte(SEND_CHEAPER, RECV_CHEAPER, “Hello World!”,
128);pm2_rawrpc_end();pm2_kill_modules(module, nb_modules);
}pm2_exit();
}
Threaded “Hello world!”
Création d’un thread Obligatoirement par pm2_thread_create
positionnement d’un certain nombre d’attributs héritage du “droit” de faire unpack
...void thread_func(void *arg){ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);pm2_rawrpc_waitdata();printf(“%s\n”, msg);
}
void sample_func(void){
pm2_thread_create(thread_func, NULL);}...
Mobilité des activités
Migration de processus légers
PM2 PM2
Pourquoi ? Régulation de charge Localité des données
Comment ? Transfert du contexte Programmes SPMD
PM2 : architecture logicielle
Légende Marcel : noyau de processus légers Madeleine : module de communication
Marcel PM2 Madeleine
Architecture (grappes, machines parallèles)
Unix (~10 versions)
Interface de programmation (RPC, migration, allocation iso-adresse)
Régulation HPF, C* C++//, Java
Applications
Marcel : des processus légers
Multiprogrammation spécialisée pour PM2 Sous-ensemble de POSIX + extensions Support pour la migration
Sérialisation des piles de threads Allocation des piles (Iso-Malloc, [Antoniu99])
Gestion mémoire optimisée (cache de piles)
Deux niveaux de threads (noyau et utilisateur) Support des machines SMP Efficacité proche du niveau utilisateur Exploitation des Scheduler Activations sous
Linux Appels systèmes bloquants (Danjean00)
Marcel: Implantation SMP
Taille du pool de threads noyaux Automatique / option en ligne de commande
Ordonnancement Round-Robin sur chaque LWP Placement sur les LWP paramétrable
marcel_attr_init(&attr);
marcel_attr_setschedpolicy(&attr, MARCEL_SCHED_FIXED(2));
marcel_create(&pid, &attr, func, arg);
...
Marcel : performances
Comparatif avec d’autres bibliothèques
Performances brutes (meilleur cas)
Opération Version « mono »
Version « SMP »
Chgt contexte 125 ns 212 ns
Création seule 536 ns 1 us
Création + termin.
833 ns 3 us
Arbre de threads
1.232 ms 6.986 ms
OS/Processeur Processus
Thread kernel
Thread user
Marcel
Linux 2.2 / PII 450
0.540 0.130 - 0.006
Solaris 2.7/ PII 350
8.622 0.214 0.160 0.009
Madeleine : objectifs
Supports des différents protocoles Système (TCP, MPC) Haut-niveau (MPI, PVM) Bas-niveau (BIP, SISCI, VIA,…)
Protocoles multi-paradigmes VIA : message-passing, remote DMA SCI : shared memory, DMA SBP : tampons statiques
Protocoles multi-modes BIP : messages courts, longs
Madeleine : communications
LRPC, Migration
Madeleine
Interface de programmation
Couche de portabilité
MPI, PVM, TCP, UDP, BIP, SISCI, VIA, SHMEM
Packing - Unpacking
Commandes:Mad_pack(cnx, buffer, len, pack_mode, unpack_mode)
Mad_unpack(cnx, buffer, len, pack_mode, unpack_mode)
Modes:Send_SAFER
Send_CHEAPER
Send_LATER
Receive_EXPRESS
Receive_CHEAPER
Emission : modes d’empaquetage
Version transmise
Pack
Modification
End_packing
Send_SAFER Send_LATER Send_CHEAPER
Réception : mode de déballage (1)
Unpack
Après Unpack
End_packing
Tampon
Données disponibles
RECV_EXPRESS
Réception : mode de déballage (2)
RECV_CHEAPER
Unpack
Après Unpack
End_packing
Tampon
Données disponibles ???
Données disponibles
Exemple: Protocole BIP/Myrinet
Processus A Processus BRéseau
Acquittement
Message
EntêteVecteur
DMA
Madeleine sur BIP/Myrinet
Madeleine/BIP
Latence : 8 µsDébit : 125 Mo/s
Migration PM2 : 52 µs
Communication contexte utilisateur (L. Prylli) Zéro copie Contrôle de flux pour les petits messages
Madeleine : résultats
Performances en latence 6 µs sur SISCI/SCI 8 µs sur BIP/Myrinet
Migration PM2 24 µs sur SISCI/SCI 52 µs sur BIP/Myrinet
Performance en bande passante 125 Mo/s sur BIP/Myrinet
World
record
Madeleine : d’autres utilisations
Bus CORBA haute performance Collaboration avec Alcatel-INRIA Communications ORB efficaces
Zéro copie avec un ORB? Intégration thread et communication (réactivité) Support du multiprotocoles
MPI-Madeleine Collaboration avec L. Prylli (LIP) Implémentation MPI
Intégration thread et communication (réactivité) Support du multiprotocoles
Compilation/exécution d’un programme PM2
Fabrication d’un profil Paramétrage de l’environnement
make xconfig- (pm2, debug, madeleine, protocole, marcel, mono-smp)- Géneration d’une flavor
Sélection du profil setenv PM2_FLAVOR=mon_profil
Compilation du programme make
Choix d’une configuration pm2conf myri0 myri1 myri2
Exécution du programme pm2load programme arg1 arg2 … argn
DSM-PM2 : mémoire partagée et multithreading
Generic, configurable Support for multiple consistency models Multi-protocol support for a given consistency model User interface :
protocol selection/specificationinitial distribution of DSM pages
Thread migration Integrated in consistency protocols Support for adaptive protocols:
page migration vs. thread migration
Compilation HPF/C* sur PM2
Irrégularité Faible Moyenne ForteBLOCK 3.69 5.34 9.51CYCLIC 5.37 4.34 5.34BLOCK +threads
3.36 3.10 5.32
BLOCK +threads + WS
3.57 2.85 4.45
Simulation de flamme
Align
Disribute
Processors
Thread
s
PM2
Equilibrage dynamique dans HPF/C* (C. Pérez) Modification des exécutifs des compilateurs Module générique d’équilibrage de charge
Compilation et PM2 (suite)
Projet Hyperion (New Hampshire) Machine virtuelle Java distribuée
Thread Java calqués sur les threads PM2 Mémoire partagée reposant sur DSM-PM2
Grappes de PC
Projet Paris (Rennes) Utilisation de Madeleine (Y. Jégou)
MOME, DSM pour un compilateur HPF
Projet NANOS (Barcelone) Environnement pour machines SMP à l’origine Portage sur PM2 et DSM-PM2 OpenMP
Lancer de rayons // (PM2)
Transfert technologique (TTN ProHPC) Société AGEMOB
Rendu 3D réaliste de mobilierServeur de calcul pour des chaines de distribution
Projet MOB3D : LIP + AGEMOB + fabricants de meuble
Calcul rapide d’une image réaliste sur réseau de stations
POV-Ray (Persistance Of Vision Ray-tracer) Domaine public, portabilité (Unix, NT) Assez largement utilisé dans la communauté
PM2POVRAY Application parallèle exploitant des grappes de
SMP
Principe de PM2POV-Ray
Scène répliquée sur chaque machine Découpage de l’image en threads
Régulation de charge Distribution cyclique des threads sur les machines Equilibrage dynamique par migration
P0
P1
P2
P3
P0
P1
P2
P3
Conclusions
Efficacité et portabilité Bon compromis obtenu pour PM2
Des collaborations Principalement pour des compilateurs et
bibliothèques Stages DEA-DESS, thèse
Disponible sur Internet http://www.pm2.org
Collaborations industrielles Microsoft, Alcatel Aérospatiale-Matra (caches Web)