Threads - RunTime

Multithreading et Calcul
Haute Performance
J-F. Méhaut, R. Namyst
INRIA, ReMaP, LIP, ENS Lyon
Au menu
 Introduction : contexte technologique
Nouvelles archis: processeurs, réseaux, etc.
 Multithreading : quels intérêts?
Définition, premiers contacts, partage mémoire
 Pause (10’)
 Multithreading distribué
Intérêts et difficultés
Quelques environnements
L’environnement PM2
 Conclusion
Introduction
Architecture processeur Cray-TERA
Applications
i=1
Threads concurrents
i=3
Streams
Pool d’instructions prêtes
Pipeline d’instructions en
cours d’exécution
3
2
1
i=2
…
j=1
F (a)
i=n
F (b)
j=3
j=2
…
4
G(A)
Programme
j=m
séquentiel
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, ...
PC
Commutateur
Myrinet/BIP
Motivations pour le haut-débit
Performances des communications
Atteindre le niveau de performance des machines parallèles
avec les équipements du marché (PC ou station de travail)
Minimiser la latence, maximiser le débit
Thématiques de recherche
Matériel
 Commutateurs, cartes d’interface
 Commutations, routage
 Logiciel
 Interfaces de communication (AM, FM, BIP, …)
 Env. de programmation (MPI, PM2, Nexus,…)
Myrinet
Objectifs
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
Host
Host
Host
Host
Carte d’interface
Carte d’interface
Carte d’interface
Carte d’interface
Myrinet commutateur
Myrinet commutateur
Crossbar complet
Câble 2,6 Gbps full duplex
Carte d’interface
Host
Carte d’interface
Host
 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)
Memory
PCI Bus
PCI
Bridge

DMA
Controler
Performance (BIP/Myrinet)
 6 microsecondes latence
 127 Mbytes/sec bande passante
RISC
Packet
Interface
LANai
Lien Myrinet
SCI*(Scalable Coherent Interface)
Réseau à capacité d’adressage
 Adressage des mémoires distantes
 Lecture/écriture distante sans interruption du processeur distant
 Support matériel pour mémoire partagée
Processus A
Processus B
PCI-SCI
Espace
d'adressage
virtuel
Interconnexion
SCI
PCI-SCI
Bus
PCI
* Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)
Bus
PCI
Mémoire
physique
Espace
d'adressage
virtuel
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
Latence
Lecture
Ecriture
Cache
L1
5 ns
5 ns
Cache
L2
60 ns
60 ns
Mémoire
SCI
120 ns
120 ns
4 µs
2 µs
Pas de cohérence sur PCI (bus d’entrées/sorties)
* Emmanuel Cecchet (Sirac, INRIA Rhône-Alpes)
SCI : performances



Latence : 2.5 ms (écriture de processus à processus)
Débit :
70 Mo/s
Verrou : < 10 ms (fetch&add)
Comms : remarques préliminaires
 Règle des 80/80
80% des messages sont de taille inférieure à 256 octets
80% du trafic provient de messages d’une taille
supérieure à 8KB
 Nouvelles approches
Latence faible pour les petits messages
Bande passante importante pour les gros messages
Coût des protocoles traditionnels
Communications système
Evolutions technologiques
Coûts logiciels des protocoles
Protocole système (TCP/UDP/IP)
Réseaux 100 Mb
Réseaux 10 Mb
Réseaux Gb
Comm. en contexte utilisateur
Recherches académiques
Processus
OS
 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
Interface
Standard industriel : VIA
 Participation des industriels
 Etendre le spectre des applications
VIA : Virtual Interface Architecture
VI Consumer
Host
Sockets, MPI,
Legacy, etc.
VI User Agent (“libvia”)
VI Kernel Agent (Slow)
User-Level (Fast)
NIC
Doorbells
Open, Connect,
Map Memory
Undetermined
Descriptor Read, Write
VI
VI
VI
C
C
S R
S R
S R
O
M
P
Requests
Completed
VI-Capable NIC
Giganet : Cartes VIA
Application
Winsock API
TCP/IP
VI API
With VIA
50 versus 7000
instructions
NDIS
Native VI Interface
Fast
Fastest
™
•
•
•
•
•
Commutateurs
Cartes d’interface
Administration du réseau
cLAN pour Windows
cLAN pour Linux
Supports d’exécution parallèle
Avantages pour les utilisateurs
Abstractions de haut niveau
Portabilité des applications
Efficacité !
Applications
Interface de programmation (API)
Support d’exécution //
Systèmes d’exploitation
Architectures parallèles et distribuées
Le multithreading :
quel(s) intérêt(s) ?
Introduction et rappels
Rappel : les processus lourds
 Caractéristiques
Entité active directement supportée par l’OS
 Flot d’exécution
 Espace d’adressage privé
 Ressources systèmes
 Exécution séquentielle
 Coût de gestion élevé
Allocation des ressources
Appels systèmes
Processus lourds (bis)
 Ressources “kernel” + données “user”
Espace utilisateur
Processus
Processus
Processus
Ordonnanceur
Noyau
processeur
processeur
processeur
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
for (;;) {
if(networkMsgIn()) getNetworkMsg();
if(kbdReady()) getKey();
if(diskBlockReady()) handleDiskBlock();
…
}
Séquence infinie d’opérations courtes
Ordre et fréquence des scrutations ?
Systèmes multiprogrammés
for (;;) {
for (;;) {
wait for key stroke;
wait for network msg;
getNetworkMsg();
getKey();
}
}
for (;;) {
wait for disk block;
handleDiskBlock();
}
Exécution indépendante des activités
Concurrence entre les différents traitements
Processus serveur classique
 Sérialisation des requêtes
client
serveur
OS
OS
Pas de recouvrement des E/S
Exploitation SMP délicate
Prise en compte de priorités ?
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
thread
ressources
 Introduits dans divers langages & systèmes
Programmation concurrente
Recouvrement des E/S
Exploitation des architectures SMP
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é)
Processus
Thread noyau
Linux 2.2/PII 450
0.540
0.130
Solaris 2.7/PII 350
8.622
0.214
OS/Processeur
Thread utilisateur
-
PM2
0.006
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
int pthread_create( pthread_t *pid,
pthread_attr_t *attr,
void * (*start_func)(void *),
void *arg);
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éé
Attente de fin d’exécution
int pthread_join(
pthread_t pid,
void **status);
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_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
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 128*1024);
pthread_create(NULL, &attr, func, NULL);
À manipuler avec précaution !
 Quelle taille de pile choisir ?
 Comment prévenir/détecter les débordements ?
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
Mov @glob, $r1 ; charger
Inc r1
; incrémenter
Mov $r1, @glob ; enregistrer
Scénario d’exécution concurrente par 2 threads :
Mov @glob, $r1
Inc r1
Mov @glob, $r1
Inc r1
Mov $r1, @glob
…
Mov $r1, @glob
Mov @glob, $r1
Inc r1
Mov @glob, $r1
Inc r1
Mov $r1, @glob
…
Mov $r1, @glob
Outils pour la synchronisation
 Exclusion mutuelle : les verrous
int glob = 0;
void *inc(void *arg)
{
for(i=0; i<100; i++) {
pthread_mutex_lock(&mutex);
glob++;
pthread_mutex_unlock(&mutex);
}
}
 Synchronisations plus complexes :
 Variables de condition (cf moniteurs de Hoare)
 pthread_cond_wait
 pthread_cond_signal, pthread_cond_bcast
Code réentrant
 « code demeurant correct lorsqu’il est
exécuté simultanément par plusieurs threads »
 Exemples typiques
Fonction n’utilisant que des variables locales
Code protégé par un verrou
 Quid du code que l’on écrit pas soi-même ?
Malloc, free, …, la bibliothéque standard
Fonctions « MT-safe »
 Option –D_REENTRANT
 Certains prototypes changent…
Importance de la synchro.
 Cohérence séquentielle de la mémoire ?
Compilateurs/Optimiseurs
 Instructions réordonnées
Processeurs modernes
 Ecritures réordonnées
On ne peut pas supposer l’ordre des écritures
 Primitives de synchronisation
Agissent comme des « barrières mémoire »
Variables spécifiques
 Pb : comment gérer les variables
globales « privées »
int my_x;
void g(void)
{
…my_x…
}
void f(void)
{
my_x = do_compute();
…
g();
}
Variables spécifiques
 Principe
Variable accessible à partir d’une clé
Allocation globale (souvent à l’initialisation)
 pthread_setspecific(clé, valeur)
 pthread_getspecific(clé) -> valeur
 Exemple : la variable errno
Fichier errno.h
#ifdef _REENTRANT
#define errno (*__errno_location())
#else
extern int errno;
#endif
A propos d’efficacité
 Les threads sont-ils toujours meilleurs
que MPI sur architectures SMP ?
 Solution « processus communicants »
Communications pénalisantes (copies)
Surcoût en utilisation de ressources
Recouvrement plus difficile
 Solution « processus légers »
Synchronisations additionnelles
Accès aux variables spécifiques coûteux
Le multithreading :
quel(s) intérêt(s) ?
Ordonnancement des threads
Multithreading utilisateur
 Deux ordonnanceurs indépendants :
User Space
Process
Process
Scheduler
Process
Scheduler
Scheduler
OS Kernel
processor
processor
processor
Multithreading noyau
 Un seul ordonnanceur :
User Space
Process
Process
Process
Scheduler
OS Kernel
processor
processor
processor
Multithreading mixte
 Deux ordonnanceurs coopérants
User Space
Process
Process
Scheduler
Process
Scheduler
Scheduler
OS Kernel
processor
processor
processor
Note: Quid des appels systèmes bloquants ?
Ordonnancement non-préemptif
 Le processus cède la main
Lorsqu’il se bloque
Lorsqu’il meurt
 Avantages
Peu de commutations de contextes
Atténuation des problèmes de réentrance
 Inconvénients
Partage non-équitable des ressources
Risque de famines
Ordonnancement préemptif
 Une horloge force les commutations
 Avantages
cf. inconvénients du non-préemptif
 Inconvénients
cf. avantages du non-préemptif
 En général
Threads noyaux  préemptif
Threads utilisateurs  non-préemptif
Choix de
l’ordonnancement
 Niveau d’ordonnancement
pthread_attr_setscope(…)
 PTHREAD_SCOPE_SYSTEM
 PTHREAD_SCOPE_PROCESS
 Classes d’ordonnancement
pthread_attr_setschedpolicy(…)
 SCHED_FIFO
 SCHED_RR
 SCHED_OTHER
Le multithreading :
quel(s) intérêt(s) ?
Recouvrement des Entrées/Sorties
Recouvrement des E/S
 Au lieu de
Espace utilisateur
Espace noyau
Temps CPU perdu
syscall
I/O request
interrupt
Matériel
 …on voudrait :
Espace utilisateur
Espace noyau
Matériel
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
Multithreading
Distribué
Principe et Enjeux
Principe
 Introduire les threads dans les
applications distribuées
proc
proc
proc
réseau
proc
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
MPI_Isend
MPI_recv
Acquittement
MPI_test
Processus A
Processus B
Multithreading
Distribué
Quel modèle de programmation ?
Approche par juxtaposition
 Principe : pas de modèle !
Simplement utiliser conjointement
 Une bibliothèque de communication (ex: MPI)
 Une bibliothèque de multithreading
 Problèmes
Conceptuels
 Pas de visibilité globale des threads
 Sémantique des communications ?
Techniques
 Compatibilité entre les bibliothèques
 Travail d’intégration spécifique -> non réutilisable
Threads communicants
 Principe
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
Multithreading
Distribué
Intégration des threads
et des communications
Progression des communications
 Problème
Comment assurer la progression des
communications ?
proc
proc
proc
réseau
proc
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
 Création d’une catégorie
de polling (ex: MPI), assignation
d’une fréquence et enregistrement
de callbacks.
 Chaque thread candidat à une
opération de polling adresse une
requête à l’ordonnanceur et se bloque.
Polling jobs
queue
MPI_Isend
Marcel_poll
MPI_Irecv
Marcel_poll
MPI
Polling(
) callback
callback
 Régulièrement, l’ordonnanceur
appelle la fonction de scrutation
définie par l’utilisateur...
Ordonnanceur
des threads
Multithreading
Distribué
L’environnement PM2
Premières réflexions sur PM2
Parallel Multithreaded Machine (R. Namyst)
Virtualisation de l’architecture
Régulateurs génériques de charge (Y. Denneulin)
Plateformes usuelles (COW, NOW), machines parallèles
Distribution du logiciel, assistance, documentation:-(
InterPRC Stratagème (C. Roucairol)
Applications irrégulières
 Optimisation combinatoire
 Algèbre linéaire creuse (J. Roman)
Ordonnancement, régulation
 Fortement irrégulière : placement + migration
Projet PM2 (95-xx)
Objectif ambitieux : virtualisation
Indépendance de la machine cible (#processeurs)
Degré de parallélisme important (#processus)
Parler de “traitement” / “processus”
 mécanismes de décomposition parallèle
Propositions
Mécanisme de décomposition
 Appel de procédure à distance léger (LRPC)
Support des activités
 Processus légers (threads)
Régulateur dynamique de charge
 Placement + Migration
Appel de procédure à distance
PM2
PM2
LRPC
Différentes déclinaisons
 Synchrone
 Attente différée
 Asynchrone
Nos concurrents...
 Nexus : RSR
 Athapascan : appels de service
Hello World!
#include <pm2.h>
unsigned SAMPLE;
void sample_func(void)
{ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);
pm2_rawrpc_waitdata();
printf(“%s\n”, msg);
}
void main(int argc, char **argv)
{ int module[MAX_MODULES], nb_modules;
pm2_rawrpc_register(&SAMPLE, sample_func);
pm2_init(&argc, argv, 2, module, &nb_modules);
if(pm2_self() == les_modules[0]) {
pm2_rawrpc_begin(module[1], SAMPLE, NULL);
pm2_pack_byte(SEND_CHEAPER, RECV_CHEAPER, “Hello World!”, 128);
pm2_rawrpc_end();
pm2_kill_modules(module, nb_modules);
}
pm2_exit();
}
Threaded “Hello world!”
 Création d’un thread
Obligatoirement par pm2_thread_create
 positionnement d’un certain nombre d’attributs
 héritage du “droit” de faire unpack
...
void thread_func(void *arg)
{ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);
pm2_rawrpc_waitdata();
printf(“%s\n”, msg);
}
void sample_func(void)
{
pm2_thread_create(thread_func, NULL);
}
...
Mobilité des activités
Migration de processus légers
PM2
Pourquoi ?
Régulation de charge
Localité des données
PM2
Comment ?
Transfert du contexte
Programmes SPMD
PM2 : architecture logicielle
Applications
Régulation
HPF, C*
C++//, Java
Interface de programmation (RPC, migration, allocation iso-adresse)
Marcel
PM2
Madeleine
Unix (~10 versions)
Architecture (grappes, machines parallèles)
Légende
Marcel : noyau de processus légers
Madeleine : module de communication
Marcel : des processus légers
Multiprogrammation spécialisée pour PM2
Sous-ensemble de POSIX + extensions
Support pour la migration
 Sérialisation des piles de threads
 Allocation des piles (Iso-Malloc, [Antoniu99])
Gestion mémoire optimisée (cache de piles)
Deux niveaux de threads (noyau et utilisateur)
Support des machines SMP
Efficacité proche du niveau utilisateur
Exploitation des Scheduler Activations sous Linux
 Appels systèmes bloquants (Danjean00)
Marcel: Implantation SMP
 Taille du pool de threads noyaux
Automatique / option en ligne de commande
 Ordonnancement
Round-Robin sur chaque LWP
Placement sur les LWP paramétrable
marcel_attr_init(&attr);
marcel_attr_setschedpolicy(&attr, MARCEL_SCHED_FIXED(2));
marcel_create(&pid, &attr, func, arg);
...
Marcel : performances
 Comparatif avec d’autres bibliothèques
OS/Processeur
Processus Thread kernel
Thread user
Marcel
Linux 2.2 / PII 450
0.540
0.130
-
0.006
Solaris 2.7/ PII 350
8.622
0.214
0.160
0.009
 Performances brutes (meilleur cas)
Opération
Version « mono »
Version « SMP »
Chgt contexte
125 ns
212 ns
Création seule
536 ns
1 us
Création + termin.
833 ns
3 us
1.232 ms
6.986 ms
Arbre de threads
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
Receive_EXPRESS
Send_CHEAPER
Receive_CHEAPER
Send_LATER
Emission : modes d’empaquetage
Pack
Send_SAFER
Send_LATER
Send_CHEAPER
Modification
End_packing
Version transmise
Réception : mode de déballage (1)
RECV_EXPRESS
Unpack
Tampon
Après Unpack
Données disponibles
End_packing
Réception : mode de déballage (2)
RECV_CHEAPER
Unpack
Tampon
Après Unpack
Données disponibles ???
End_packing
Données disponibles
Exemple: Protocole BIP/Myrinet
Processus A
Réseau
Processus B
Message
Acquittement
DMA
Entête
Vecteur
Madeleine sur BIP/Myrinet
Communication contexte utilisateur (L. Prylli)
Zéro copie
Contrôle de flux pour les petits messages
Madeleine/BIP
Latence : 8 µs
Débit : 125 Mo/s
Migration PM2 : 52 µs
Madeleine : résultats
Performances en latence
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
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/specification
initial distribution of DSM pages
Thread migration
Integrated in consistency protocols
Support for adaptive protocols:
page migration vs. thread migration
Compilation HPF/C* sur PM2
Equilibrage dynamique dans HPF/C* (C. Pérez)
Modification des exécutifs des compilateurs
Module générique d’équilibrage de charge
Simulation de flamme
Align
Disribute
Processors
Irrégularité
BLOCK
CYCLIC
BLOCK +
threads
BLOCK +
threads + WS
Faible
3.69
Moyenne
5.34
Forte
9.51
5.37
3.36
4.34
3.10
5.34
5.32
3.57
2.85
4.45
Compilation et PM2 (suite)
Projet Hyperion (New Hampshire)
Machine virtuelle Java distribuée
 Thread Java calqués sur les threads PM2
 Mémoire partagée reposant sur DSM-PM2
Grappes de PC
Projet Paris (Rennes)
Utilisation de Madeleine (Y. Jégou)
MOME, DSM pour un compilateur HPF
Projet NANOS (Barcelone)
 Environnement pour machines SMP à l’origine
 Portage sur PM2 et DSM-PM2
 OpenMP
Lancer de rayons // (PM2)
Transfert technologique (TTN ProHPC)
Société AGEMOB
Rendu 3D réaliste de mobilier
Serveur de calcul pour des chaines de distribution
Projet MOB3D : LIP + AGEMOB + fabricants de meuble
Calcul rapide d’une image réaliste sur réseau de stations
POV-Ray (Persistance Of Vision Ray-tracer)
Domaine public, portabilité (Unix, NT)
Assez largement utilisé dans la communauté
PM2POVRAY
Application parallèle exploitant des grappes de SMP
Principe de PM2POV-Ray
Scène répliquée sur chaque machine
Découpage de l’image en threads
Régulation de charge
Distribution cyclique des threads sur les machines
Equilibrage dynamique par migration
P0
P1
P2
P3
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)