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)