Environnement Logiciel pour le calcul scientifique

Transcription

Environnement Logiciel pour le calcul scientifique
Patrick Amestoy et Michel Daydé (ENSEEIHT-IRIT)
préparé en collaboration avec
J.-Y. L’Excellent (INRIA/LIP-ENS Lyon)
2015-2016
1 / 220
Outline
Introduction
Introduction aux calculateurs haute-performance
Evolutions architecturales
Programmation
Conclusion
2 / 220
Outline
Introduction
Programmation
Conclusion
3 / 220
I
Intérêts du Calcul Haute-Performance
I
I
I
I
I
Applications temps-critique
Cas de calcul plus gros
Diminution du temps de réponse
Minimisation des coûts de calcul
Difficultés
I
Accès aux données : hiérarchie mémoire complexe
→ Exploiter la localité des références aux données
I
Identification et gestion du parallélisme dans une application
→ Approche algorithmique
4 / 220
Systèmes parallèles:
I
I
I
I
I
I
I
Les machines les plus puissantes sont à haut degré de
parallélisme
Le rapport prix / performance est attractif
Plus que quelques constructeurs dans la course
Systèmes plus stables
Logiciels applicatifs et librairies disponibles
Exploitation industrielle et commerciale : plus uniquement
laboratoires de recherche
Mais: travail algorithmique important et validation/maintenance
difficile.
Nouvelles évolutions:
I
1 core per chip → multi-core chips
I
Graphycal Processing units (GPU)
I
supercomputing → métacomputing (“grid computing”)
5 / 220
Classes de calculateurs
I
Serveurs de calcul :
I
I
I
I
Calculateurs plus spécifiques :
I
I
I
I
I
Utilisables sur une large gamme d’applications
Multiprogrammation et temps partagé
Stations de travail, serveurs départementaux, centre de calcul
Efficaces sur une classe plus limitée de problèmes (haut degré de
parallélisme)
A cause de leur architecture ou de limitations du logiciel
Par exemple architectures massivement parallèles (MPP, clusters
de PC,.....)
Gains importants possibles avec rapport coût-performance
intéressant
Calculateurs spécialisés :
I
I
I
I
Résolution d’un problème (image processing, crash test, . . . )
Hardware et logiciels conçus pour cette application-cible
Gains très importants possibles avec un rapport coût-performance
très intéressant
Par exemple, la machine MDGRAPE-3 (dynamique moléculaire)
installée au Japon atteint 1 PFlop/s !
6 / 220
Besoins dans le domaine du calcul scientifique
Science traditionnelle
1. Construire une théorie, puis effectuer des expériences ou construire un
système.
I
I
I
I
trop difficile (ex: souffleries de grandes tailles)
trop cher (fabriquer un avion juste pour quelques
expérimentations)
trop lent (attente de l’évolution du climat / de l’univers)
trop dangereux (armes, médicaments, expérimentations sur le
climat)
Calcul scientifique
I
simuler le comportement de systèmes complexes grâce à la simulation
numérique.
I
lois physiques + algorithmes numériques + calculateurs HPC
7 / 220
Exemples dans le domaine du calcul scientifique
I
Contraintes de durée: prévision du climat
8 / 220
Quelques exemples dans le domaine du calcul scientifique
I
Cost constraints: wind tunnels, crash simulation, . . .
9 / 220
Scale Constraints
I
large scale: climate modelling, pollution, astrophysics
I
tiny scale: combustion, quantum chemistry
10 / 220
Pourquoi des traitements parallèles ?
I
Besoins de calcul non satisfaits dans beaucoup de disciplines
(pour résoudre des problèmes significatifs)
I
Performance uniprocesseur proche des limites physiques
Temps de cycle 0.5 nanoseconde (fréq: 2GH)
↔ 8 GFlop/s (avec 4 opérations flottantes / cycle)
I
Calculateur 40 TFlop/s ⇒ 5000 coeurs
→calculateurs massivement parallèles
I
Pas parce que c’est le plus simple mais parce que c’est nécessaire
Puissance actuelle (cf http://www.top500.org):
Juin 2010, Cray XT5, Oak Ridge Natl Lab, 1.7Pflops,
300Tbytes, 224K coeurs
Juin 2013, TH-IVB cluster, NUDT (Chine), 33.8Pflops,
1PetaByte, 3M coeurs
11 / 220
Quelques unités pour le calcul haute performance
Vitesse
Megaflop/s 106 opérations / seconde
Gigaflop/s
109 opérations / seconde
Teraflop/s
Petaflop/s 1015 opérations / seconde
Exaflop/s
Mémoire
1 MB / 1 Mo 1 Megabyte
106 octets
1 GB / 1 Go
1 Gigabyte
109 octets
1 TB / 1 To
1 Terabyte
1012 octets
1 PB / 1 Po
1 Petabyte
1015 octets
1 EB / 1 Eo
1 Exabyte
1018 octets
Origines grecques des préfixes : kilo (mille); Mega (grand); Giga
(géant); Tera (monstre); Peta (cinq); Exa (six)
1
1
1
1
1
MFlop/s
GFlop/s
TFlop/s
PFlop/s
EFlop/s
1
1
1
1
1
12 / 220
Mesures de performance
I
I
Nombre d’opérations flottantes par seconde (pas MIPS)
Performance crête :
I
I
I
I
Ce qui figure sur la publicité des constructeurs
Suppose que toutes les unités de traitement sont actives
On est sûr de ne pas aller plus vite :
#unités fonctionnelles
Performance crête =
clock (sec.)
Performance réelle :
I
Habituellement très inférieure à la précédente
Malheureusement
13 / 220
Rapport (Performance réelle / performance de crête) souvent bas !!
Soit P un programme :
1. Processeur séquentiel:
I
I
1 unité scalaire (1 GFlop/s)
Temps d’exécution de P : 100 s
2. Machine parallèle à 100 processeurs:
I
I
Chaque processor: 1 GFlop/s
Performance crête: 100 GFlop/s
3. Si P : code séquentiel (10%) + code parallélisé (90%)
I
I
4.
Temps d’exécution de P : 0.9 + 10 = 10.9 s
Performance réelle : 9.2 GFlop/s
Performance réelle = 0.1
Performance de crête
14 / 220
Loi d’Amdahl
I
fs fraction d’une application qui ne peut pas être parallélisée
fp = 1 − fs fraction du code parallélisé
N: nombre de processeurs
I
Loi d’Amdahl:
f
tN ≥ ( Np + fs )t1 ≥ fs t1
Speed-up: S =
t1
tN
≤
1
f
fs + Np
≤
1
fs
Sequential
t∞
= fs t1
Parallel
t3
t2
t1
15 / 220
Calculateur
Intel WoodCrest (1 core, 3GHz)
HP ProLiant (1 core, 3.8GHz)
HP ProLiant (1 core, 3.8GHz)
IBM eServer(1.9GHz, Power5)
IBM eServer(1.9GHz, Power5)
Fujitsu Intel Xeon (3.2GHz)
Fujitsu Intel Xeon (3.2GHz)
SGI Altix (1.5GHz Itanium2)
NEC SX-8 (2 GHz)
Cray T932
Hitachi S-3800/480
procs
1
1
2
1
8
1
2
1
1
32
4
LINPACK
n = 100
3018
1852
1776
1679
1659
2177
1129 (1 proc.)
408 (1 proc.)
LINPACK
n = 1000
6542
4851
8197
5872
34570
3148
5151
5400
14960
29360
20640
Perf.
crête
12000
7400
14800
7600
60800
12800
6400
6000
16000
57600
32000
Table : Performance (MFlop/s) sur la résolution d’un système d’équations
linéaires (d’après LINPACK Benchmark Dongarra [07])
16 / 220
Machine
PFlop/s computer
TFlop/s computer
CM2 64K
CRAY-YMP-8
ALLIANT FX/80
SUN 4/60
VAX 11/780
IBM AT
APPLE MAC
Problème de
petite taille
2 secondes
30 minutes
4 heures
5 jours
1 mois
9 mois
9 ans
23 ans
Problème de
grande taille
36 secondes
10 heures
1 an
10 ans
250 ans
1500 ans
14,000 ans
170,000 ans
450,000 ans
Table : Vitesse de certains calculateurs sur un problème Grand Challenge en
1995 (d’après J.J. Dongarra)
17 / 220
Machine
PFlop/s computer
TFlop/s computer
CM2 64K
CRAY-YMP-8
ALLIANT FX/80
SUN 4/60
VAX 11/780
IBM AT
APPLE MAC
Problème de
petite taille
2 secondes
30 minutes
4 heures
5 jours
1 mois
9 mois
9 ans
23 ans
Problème de
grande taille
36 secondes
10 heures
1 an
10 ans
250 ans
1500 ans
14,000 ans
170,000 ans
450,000 ans
Table : Vitesse de certains calculateurs sur un problème Grand Challenge en
1995 (d’après J.J. Dongarra)
Depuis, les problèmes “Grand Challenge” ont grossi !
18 / 220
Outline
Introduction
Programmation
Conclusion
19 / 220
Evolutions architecturales: historique
I
I
Pour 1,000 $ : calculateur personnel plus performant, avec plus
de mémoire et plus de disque qu’un calculateur des années 70
avec 1,000,000 $
technologie et conception !
Durant les 25 premières années de l’informatique progrès :
technologie et architecture
Depuis les années 70 :
I
I
I
conception basée sur les circuits intégrés
performance : +25-30% par an pour les “mainframes” et minis
qui dominaient l’industrie
Depuis la fin des années 70 : émergence du microprocesseur
I
I
I
meilleure exploitation des avancées dans l’intégration que pour les
mainframes et les minis (intégration moindre)
progression et avantage de coût (production de masse) : de plus
en plus de machines sont basées sur les microprocesseurs
possibilité de pourcentage d’amélioration plus rapide = 35% par
an
20 / 220
Evolutions architecturales: historique
I
Deux changements sur le marché facilitent l’introduction de
nouvelles architectures :
1. utilisation décroissante de l’assembleur (compatibilité binaire
moins importante)
2. systèmes d’exploitation standards, indépendants des architectures
(e.g. UNIX)
⇒ développement d’un nouvel ensemble d’architectures : RISC
à partir de 85
I
I
performance : + 50% par an !!!
Conséquences :
I
plus de puissance :
I
I
I
Performance d’un PC > CRAY C90 (95)
Prix très infèrieur
Domination des microprocesseurs
I
I
I
I
PC, stations de travail
Minis remplacés par des serveurs à base de microprocesseurs
Mainframes remplacés par des multiprocesseurs à faible nombre
de processeurs RISC (SMP)
Supercalculateurs à base de processeurs RISC (essentiellement
MPP)
21 / 220
Moore’s law
I
I
I
Gordon Moore (co-fondateur d’Intel) a prédit en 1965 que la
densité en transitors des circuits intégrés doublerait tous les 24
mois.
A aussi servi de but à atteindre pour les fabriquants.
A été déformé:
I
I
24 → 18 mois
nombre de transistors → performance
22 / 220
Comment accroı̂tre la vitesse de calcul ?
I
Accélérer la fréquence avec des technologies plus rapides
On atteint les limites:
I
I
I
I
Conception des puces
Consommation électrique et chaleur dissipée
Refroidissement ⇒ problème d’espace
On peut encore miniaturiser, mais:
I
I
I
pas indéfiniment
résistance des conducteurs (R = ρ×l
s ) augmente et ..
la résistance est responsable de la dissipation d’énergie (effet
Joule).
effets de capacités difficiles à maı̂triser
Remarque: 0.5 nanoseconde = temps pour qu’un signal parcourt
15 cm de cable
I
Temps de cycle 0.5 nanosecond ↔ 8 GFlop/s (avec 4 opérations
flottantes par cycle)
23 / 220
Seule solution: le parallélisme
I
I
parallélisme: exécution simultanée de plusieurs instructions à
l’intérieur d’un programme
A l’intérieur d’un processeur :
I
I
I
micro-instructions
traitement pipeliné
recouvrement d’instructions exécutées par des unités distinctes
→ transparent pour le programmeur
(géré par le compilateur ou durant l’exécution)
I
Entre des processeurs ou cœurs distincts:
I
suites d’instructions différentes exécutées
→ synchronisations implicites (compilateur, parallélisation
automatique) ou explicites (utilisateur)
24 / 220
Unités centrales haute-performance
Concept clé: Traitement pipeliné :
I
L’exécution d’une opération (arithmétique) est décomposée en
plusieurs sous-opérations
I
Chaque sous-opération est exécutée par une unité fonctionnelle
dédiée = étage (travail à la chaine)
I
Exemple pour une opérations diadique (a ← b × c) :
T1.
T2.
T3.
T4.
T5.
Séparer mantisse et exposant
Multiplier mantisses
Additionner les exposants
Normaliser le résultat
Ajouter signe au résultat
25 / 220
Exemple pour des opérations diadiques (suite)
I
Supposition: l’opération a ← b × c s’effectue en 5 traitements
élémentaires T1,T2,. . . ,T5 d’un cycle chacun. Quel est le
nombre de cycles processeur pour la boucle suivante ?
Pour i = 1 à N
A(i) = B(i) * C(i)
Fin Pour
I
I
Traitement non pipeliné: N * 5 cycles
Traitement pipeliné (à la chaine): N + 5 cycles
I
I
I
I
I
I
1er cycle: T1(1)
2ème cycle: T1(2), T2(1)
3ème cycle: T1(3), T2(2), T3(1)
...
kème cycle: T1(k), T2(k-1), T3(k-2), T4(k-3), T5(k-4)
...
26 / 220
Impact de l’approche CRAY
L’approche CRAY (années 80) a eu un grand impact sur la
conception des supercalculateurs :
I
horloge la plus rapide possible
I
unité vectorielle pipelinée sophistiquée
I
registres vectoriels
I
mémoire très haute performance
I
multiprocesseurs à mémoire partagée
processeurs vectoriels
I
I
I
I
I
exploitent la régularité des traitements sur les éléments d’un
vecteur
traitement pipeliné
couramment utilisés sur les supercalculateurs
vectorisation par le compilateur
27 / 220
Processeurs RISC
I
Processeurs RISC : introduits sur le marché vers 1990
I
I
I
I
CISC (Complex Instruction Set Computer)
I
I
pipeline sur les opérations scalaires
performance proche de celle des processeurs vectoriels à
fréquence égale
plus efficaces sur des problèmes scalaires
Efficacité par un meilleur encodage des instructions
RISC (Reduced Instruction Set Computer)
I
I
Concept étudié fin des années 70
Décroı̂tre le nombre de cycles par instruction à 1
Jeu d’instructions simple
↓
Hardware simplifié
↓
Temps de cycle plus faible
28 / 220
I
Idées maı̂tresses dans la conception des RISC :
I
I
I
I
I
I
I
Instructions décodées en 1 cycle
Uniquement l’essentiel réalisé au niveau du hardware
Interface load/store avec la mémoire
Utilise intensivement le principe du pipeline pour obtenir un
résultat par cycle même pour les opérations complexes
Hiérarchie mémoire haute-performance
Format d’instructions simple
RISC super scalaires ou superpipelines: plusieurs unités
fonctionnelles
29 / 220
Architectures multi-cœurs
Constats
I
La quantité de composants / puce va continuer à augmenter
I
La fréquence ne peut plus augmenter beaucoup
(chaleur/refroidissement)
I
Il est difficile de trouver suffisamment de parallélisme dans le flot
d’instructions d’un processus
Multi-cœurs
I
plusieurs cœurs à l’intérieur d’un même processeur
I
vus comme plusieurs processeurs logiques par l’utilisateur
I
Mais: multi-threading nécessaire au niveau de l’application
30 / 220
Processeur Cell
I
La PS3 est basée sur un processeur
Cell (Sony,Toshiba,IBM)
I
1 Cell= un Power PC + 8 SPE
(Synergetic Process. Elem.)
I
1 SPE = processeur vectoriel SIMD
+ DMA = 25.6 GFlop/s
I
204 GFlop/s de performance crête
en arithmétique 32 bits
(14.6 GFlop/s en 64 bits)
I
D’où regain d’intérêt pour le calcul en 32 bits
I
I
I
Mélange d’arithmétiques simple et double précision (voir [10])
Typiquement: 32-bit pour le gros des calculs, 64 bits pour
améliorer la précision
Pas seulement sur processeur Cell
Example of mixed-precision arithmetic
I
I
Solve Ax = b, A sparse with the sparse direct solver MUMPS
Compare single precision + iterative refinement to double
precision run (Number of steps of iterative refinements indicated
on Figure).
Speed-up obtained wrt double precision
(Results from A. Buttari et.al., 2007)
32 / 220
Année
1955-65
1965-75
1975-85
1985-1995
1995-2005
2008 -
Calculateur
CDC 6600
CDC 7600
IBM 370/195
ILLIAC IV
CRAY-1, XMP, CRAY 2
CDC CYBER 205
FUJITSU VP400
NEC SX-2
CRAY-YMP, C90
ETA-10
NEC SX-3
FUJITSU VP2600
CRAY T3E
INTEL
IBM SP
HP
NEC
IBM Blue Gene
Roadrunner
MFlop/s
1-10
10 - 100
100 - 1000
1000 - 100,000
1.2 TFlop/s
1.8 TFlop/s
16 TFlop/s
20 TFlop/s
40 TFlop/s
180 TFlop/s
1 PFlop/s
Table : Evolutions des performances par décennie
Problèmes
I
I
On est souvent (en pratique) à 10% de la performance crête
Processeurs plus rapides → accès aux données plus rapide :
I
I
organisation mémoire,
communication inter-processeurs
I
Hardware plus complexe : pipe, technologie, réseau, . . .
I
Logiciel plus complexe : compilateur, système d’exploitation,
langages de programmation, gestion du parallélisme,
. . . applications
Il devient plus difficile de programmer efficacement
34 / 220
Problèmes de débit mémoire
I
L’accès aux données est un problème crucial dans les
calculateurs modernes
I
Accroı̂ssement de la vitesse de calcul sans accroı̂tre le débit
mémoire → goulet d’étranglement
MFlop/s plus faciles que MB/s pour débit mémoire
I
Temps de cyle processeurs → 2 GHz (.5 ns)
Temps de cycle mémoire
→ ≈ 20 ns SRAM
≈ 50 ns DRAM
35 / 220
Comment obtenir de hauts débits mémoire ?
I
Plusieurs chemins d’accès entre mémoire et processeurs
I
CRAY XMP et YMP :
I
I
I
NEC SX :
I
I
2 vector load + 1 vector store + 1 I/O
utilisés pour accéder des vecteurs distincts
chemins d’accès multiples peuvent être aussi utilisés pour charger
un vecteur
(améliore le débit, mais pas la latence !)
I
Plusieurs modules mémoire accédés simultanément (entrelaçage)
I
Accès mémoire pipelinés
I
Mémoire organisée hiérarchiquement
La façon d’accéder aux données peut affecter la performance:
I
I
I
I
Minimiser les défauts de cache
Minimiser la pagination mémoire
Localité: améliorer le rapport références à des mémoires locales/
références à des mémoires à distance
36 / 220
Size
Average access time (# cycles) hit/miss
Registers
1 − 128 KB
256 KB − 16 MB
1 − 10 GB
Cache level #1
Cache level #2
Main memory
Remote memory
Disks
<1
1−2 / 8 − 66
6−15 / 30 − 200
10 − 100
500 − 5000
700,000 / 6,000,000
Figure : Exemple de hiérarchie mémoire.
37 / 220
Conception mémoire pour nombre important de
processeurs ?
Comment 500 processeurs peuvent-ils avoir accès à des données
rangées dans une mémoire partagée (technologie, interconnexion, prix
?)
→ Solution à coût raisonnable : mémoire physiquement distribuée
(chaque processeur a sa propre mémoire locale)
I 2 solutions :
I
I
I
Scalibité impose :
I
I
I
mémoires locales globalement adressables : Calulateurs à
mémoire partagée virtuelle
transferts explicites des données entre processeurs avec échanges
de messages
augmentation linéaire débit mémoire / vitesse du processeur
augmentation du débit des communications / nombre de
processeurs
Rapport coût/performance → mémoire distribuée et bon rapport
coût/performance sur les processeurs
38 / 220
Architecture des multiprocesseurs
Nombre élevé de processeurs → mémoire physiquement distribuée
Organisation
logique
Partagée
Distribuée
Organisation physique
Partagée (32 procs max)
Distribuée
multiprocesseurs
espace d’adressage global
à mémoire partagée
(hard/soft) au dessus de messages
mémoire partagée virtuelle
émulation de messages
échange de messages
(buffers)
Table : Organisation des processeurs
Remarque: standards de programmation
Organisation logique partagée:
Organisation logique distribuée:
threads, OpenMP
PVM, MPI, sockets
39 / 220
Remarques
Mémoire physiquement partagée
Temps d’accès uniforme à toute la mémoire
Mémoire physiquement distribuée
Temps d’accès dépend de la localisation de la donnée
Mémoire logiquement partagée
I
Espace d’adressage unique
I
Communications implicites via la mémoire partagée
Mémoire logiquement distribuée
I
Plusieurs espaces d’adressage privés
I
Communications explicites (messages)
Terminologie
Architecture SMP (Symmetric Multi Processor)
I
Mémoire partagée (physiquement et logiquement) et temps
d’accès uniforme à la mémoire
I
Similaire du point de vue applicatif aux architectures
multi-cœurs (1 cœur = 1 processeur logique)
I
Mais communications bcp plus rapides dans les multi-cœurs
(latence < 3ns, bande passantee > 20 GB/s) que dans les SMP
(latence ≈ 60ns, bande passantee ≈ 2 GB/s)
Architecture NUMA (Non Uniform Memory Access)
I
Mémoire physiquement distribuée et logiquement partagée (plus
facile d’augmenter le nombre de procs qu’en SMP)
I
Temps d’accès dépend de la localité (accès locaux plus rapides ;
hardware assure cohérence des caches (ccNUMA))
41 / 220
Outline
Introduction
Programmation
Conclusion
42 / 220
Classification de Flynn
I
S.I.S.D. : Single Instruction Single Data stream
I
I
I
I
architecture monoprocesseur
calculateur von Neumann conventionnel
exemples : SUN, PC
S.I.M.D. : Single Instruction Multiple Data stream
I
I
I
I
I
processeurs exécutent de façon synchrone la même instruction sur
des données différentes (e.g. éléments d’un vecteur, d’une
matrice, d’une image)
une unité de contrôle diffuse les instructions
processeurs identiques
Exemples : CM-2, DAP, MasPar,. . .
plus récemment: chacun des 8 SPE du processeur CELL se
comporte comme un système SIMD
43 / 220
I
I
M.I.S.D. : n’existe pas
M.I.M.D. : Multiple Instructions Multiple Data stream
I
I
I
processeurs exécutent de façon asynchrone des instructions
différentes sur des données différentes
processeurs éventuellement hétérogènes
chaque processeur a sa propre unité de contrôle
44 / 220
Modes de programmation SIMD et MIMD
I
Avantages du SIMD :
I
I
I
I
I
Facilité de programmation et de débogage
Processeurs synchronisés → coûts de synchronisation minimaux
Une seule copie du programme
Décodage des instructions simple
Avantages du MIMD :
I
I
Plus flexible, beaucoup plus général
Exemples:
I
I
mémoire partagée: OpenMP, threads POSIX
mémoire distribuée: PVM, MPI (depuis C/C++/Fortran)
45 / 220
Outline
Introduction
Programmation
Conclusion
46 / 220
Evolutions du Calcul Haute-Performance
I
Mémoire virtuellement partagée :
I
I
I
Clusters de machines
I
I
Souvent à base de noeuds multicoeurs avec ou sans accélérateurs
Programmation parallèle hybride capable d’exploiter : mémoire
partagée et multicoeurs, transfert de message, data parallèle
I
I
clusters
Hiérarchie mémoire plus étendue
Efforts de définition de standards : Open MP et threads POSIX,
MPI, HPF, . . .
MPPs et clusters
I
I
I
représentent l’avenir pour le calcul haute-performance
rapport communications souvent faible par rapport aux
puissance de calcul
multiprocesseurs à mémoire partagée
intégration dans l’ensemble des moyens de calcul d’une entreprise
de plus en plus courante
47 / 220
Environnements de programmation
I
I
On n’évitera pas le calcul parallèle
Logiciels ont toujours un temps de retard / aux architectures
I
I
I
I
Système d’exploitation
Parallélisation automatique
Logiciels applicatifs et librairies scientifiques
Pour des architectures massivement parallèles :
I
I
I
I
Standard de programmation : MPI ou MPI + threads
(POSIX/OpenMP)
Langages: le plus souvent C ou Fortran
Besoins d’outils de dévelopement (débogueurs, compilateurs,
analyseurs de performance, librairies, . . . )
Développements/maintenance difficiles et difficultés d’utilisation
des outils de mise au point.
48 / 220
Pe
er
to
(SE peer
TI@
ho
me
)
Gr
id−
bas
ed
com
Ne
pu
tw
tin
ork
g
of
ws
Be
ow
ul
Clu f clus
ter
spe sters
cia w/
l in
ter
con
Pa
nec
ral
t
lel
dis
tm
e
TF
m
lop
ma
chi
nes
HPC Spectrum (d’après J.Dongarra)
Distributed Systems
Massively // Systems
- Gather (unused) resources steal cycles
- System software manages
resources
- 10% - 20% overhead is OK
- Resources drive applications
- Completion time not critical
- Time-shared - heterogeneous
- Bounded set of resources
- Apps grow to consume all cycles
- Application manages resources
- 5% overhead is maximum
- Apps drive purchase of
equipment
- Real-time constraints
- Space-shared - homogeneous
49 / 220
Outline
La programmation par mode message
Contexte informatique, objectifs et besoins
Le modèle de programmation par transfert de messages
Envoi et réception de messages
Choisir un mode de communication
50 / 220
Outline
51 / 220
Contexte informatique
I
Multiprocesseur à mémoire distribuée ou réseau de stations de
travail
computer #2
network #1
cluster
computer #1
network #2
multiprocessor
Exemple de réseau de calculateurs.
52 / 220
Objectifs et besoins
I
I
But : répartir/gérer des calculs sur la machine cible
Outils nécessaires : ( minimum )
I
I
I
I
I
I
I
Sécurité et droits d’accés (machines et données)
Création de processus distants
Communication entre processus
Synchronisation entre processus
Gestion de la cohérence des donnés et des traitements
Séquenceur des tâches réparties
Gestion dynamiques des processeurs et des processus
(gestion des pannes, gestion de points de reprises)
53 / 220
Outline
54 / 220
I
Permet d’exprimer la communication et la synchronisation
I
C’est le modèle le plus répandu en calcul réparti
mais ce n’est pas le seul (voir par ex. LINDA )
I
Il n’apporte pas de solution à tous les problèmes posés.
Caractéristiques :
I
I
I
I
I
expression du parallélisme à la charge du programmeur
distribution des données à la charge du programmeur
l’échange de données est explicite
prise en compte possible d’un réseau hétérogènes de calculateurs
avec gestion des pannes.
55 / 220
Modèle pelure d’oignon pour l’échange de message
Chaque niveau peut-être construit au dessus du précédent
I
Niveau le plus bas : adressage au niveau canal
I
I
I
I
I
I
procédures pour transférer des paquets sur des liens
Adressage au niveau processus
éventuellement plus d’un processus par processeur
échange de message en donnant l’adresse d’un processus
Exemples : Nx sur iPSC, Vertex sur nCUBE, Express, PARMACS,
PVM, MPI, . . .
Niveau plus élevé d’abstraction : mémoire partagée virtuelle,
LINDA, espace de tuples partagé ou réparti)
56 / 220
Hypothèse d’exécution
I
Machine complètement connectée
I
Routeur automatique de messages
Machine 1
Machine 2
Processus
P22
P11
P21
P12
P31
Machine 3
les deux hypothèses ci-dessus ne sont pas toujours vraies
(Transputers)
57 / 220
Bibliotèques portables pour la programmation
d’applications parallèles distribuées
I
P4 de l’Argonne National Laboratory
I
I
I
I
I
PICL de l’Oak Ridge National Laboratory portable sur une large
gamme de multiprocesseurs à mémoire distribuée
PVM : Univ. Tennessee, Univ. Emory, Oak Ridge Nat. Lab., . . .
I
I
I
offre à la fois les modèles mémoire partagée et transfert de
message
communications entre processus
disponible et optimisé sur une large gamme de calculateurs (et
réseaux de calculateurs)
pour réseaux hétérogènes de calculateurs
aussi disponible sur multiprocesseurs
MPI : le standard pour le transfert de message
58 / 220
Outline
59 / 220
Un arbre qui cache la forêt
60 / 220
Environnement d’exécution des communications
I
I
Chaque processus est identifié par un numéro d’instance
(rang dans un groupe ou communicateur)
L’enveloppe d’un message doit permettre la caractérisation et
le traitement du message. Elle contient:
1.
2.
3.
4.
5.
le numéro de l’émetteur
le numéro du récepteur
le label du message
la taille du message
...
61 / 220
Types de communication classiques
I
I
communications point à point (one-to-one) :
échange d’information entre 2 processus
communications collectives ( dans groupe / communicateur ) :
I
I
I
one-to-many (broadcast, fan-out) :
d’un processus vers un ensemble de processus
many-to-one (collect, fan-in) :
un processus collecte des informations issues d’un ensemble de
processus
many-to-many :
échange global d’informations entre plusieurs processus
62 / 220
Communications point à point
(quelques questions)
I
Processus
Source
Dest
Send (Dest, data)
Recv(Source, data)
data
data
Temps
I
I
I
I
Questions:
Synchronisation entre l’envoi et la réception ?
Quand peut-on réutiliser la donnée envoyée ?
Bufferisation des communications ?
63 / 220
Outline
64 / 220
(Communications Synchrones/ Asynchrones)
I
Envoi/réception synchrones:
Le premier arrivé attend l’autre (notion de rendez-vous).
I
Envoi/Réception asynchrones:
L’émetteur et le récepteur ne s’attendent pas.
I
Un envoi asynchrone peut cependant être bloqué par la non
consommation du message par le récepteur
(ceci sera détaillé par la suite)
I
L’èmetteur et le récepteur n’ont pas à être tous les deux
synchrones/asynchrones !!
65 / 220
Trace d’éxecution(8 proc. CRAY T3E)
Algorithme Asynchrone
8.9s
Process 0 5 5
5
5
4
8.95s
4 5
108
5
5
5
108 5
5
Algorithme Synchrone
9.0s
5
5
5
5 Facto_L1
4 5
9.28s
Process 1
108
4
4
108 5
5
5
5
5
5
Facto_L1
9.3s
9.32s
4
Process 0
Process 2
Process 3
108 4
5
5
5
4
4 108
5
108
5
5
5
5
5
5
5
5
5
4 108
5
5
5
5
5
5
108
5
108 5
4 108 5
5
Process 1
80
80
80
80
80
80
80
80
Process 2
80
80
80
80
80
80
80
80
80
Process 5
80
80
80
80
80
80
80
80
80
Process 6
80
80
80
80
80
80
80
80
80
Process 3
Process 4
4
108
5
5
4
5
5
5
5
Process 5 4
4 4
5 5
4 108 5
5
5
5
5
5
108
5
108
5
5
2
2
2
2
5
5
108
5
108 5
2
2
108 5
5
4 108 5
5
Process 4
Process 6
4
Process 7
108
4 108
4
4 108 2 2
5
5
2
5
5
2
5
5
2 2
5
Process 7
L
(Algorithmes de factorisation LU de matrices creuses développés à
l’ENSEEIHT (asynchrone) et au NERSC, Berkeley (synchrone) )
66 / 220
Envoi/Réception bloquants ou non bloquants
I
Envoi/Réception bloquants:
La ressource est disponible en retour de la procédure.
I
Réception non-bloquante simple
un paramètre de retour indique si l’information est disponible.
I
Envoi/Réception non-bloquants généraux :
-Retour de la procédure sans garantir que la donnée ait été
envoyée/reçue.
-L’utilisateur ne peut pas réutiliser l’espace mémoire associé (au
risque de changer ce qui sera envoyé).
-Il faut donc pouvoir tester/attendre la libération (si envoi) ou la
réception effective de la donnée. Send/Recv ( Dest/Source,
data, Ireq) renvoie aussi un numéro de requête
Test ( Ireq ) et Wait ( Ireq )
67 / 220
Envoi asynchrone : bloquant et non-bloquant
Envoi asynchrone bloquant
Envoi asyncrhone non−bloquant
Send (Dest, data,Ireq)
Send (Dest, data)
Attente
Test (Ireq)
(par ex. copie dans buffer interne)
Actif
Actif
data modifiable (pas tjrs recue)
Recv(Source, data)
Wait (Ireq)
data modifiable (pas tjrs recue)
Temps
Recv(Source, data)
68 / 220
Réceptions bloquantes asynchrones
Réception non−bloquante simple
Réception non−bloquante générale
Recv (Dest, data,Ireq)
Recv(Source, data,Recu)
Send (Dest, data)
Si ( Recu ) alors
traiter data
Fin Si
Test (Ireq)
Wait (Ireq)
Send (Dest, data)
ATTENTE
Temps
(indépendant du mode d’envoi)
69 / 220
Où va l’information envoyée ?
Source
Destination
Send (Dest, data)
Buffer envoi
Réseau
Buffer réception
Recv(Dest, data)
I
Le(s) buffer(s) sont soit internes à la couche système soit gérés
par l’utilisateur.
70 / 220
Proprietés de la communication bufférisée
I
I
I
I
Buffer(s) implique(ent) copies multiples
(coût mémoire et temps)
Même dans un mode bloquant l’envoyeur peut être libre
immédiatement
Si Taille(buffer d’envoi) ≥ Taille (message) alors
( envoi asynchrone bloquant ≡ envoi non-bloquant )
Attention à gérer la saturation des buffers
(deadlock possible !!! )
Destination
Source
Send (Dest, data)
Send (Source, data)
Buffer envoi
Réseau
Buffer envoi
si l’envoi est asynchrone (bloquant) l’envoi peut être bloqué
jusqu’au lancement de la réception correspondante.
71 / 220
Propriétés des communications
I
Diffusion des messages ordonnancée FIFO :
les messages issus de Proc1 sont reçus dans l’ordre par Proc2.
Proc 1
Temps
Proc 2
I
Par contre PAS d’ordonnancement causal
Proc 1
Temps
Proc 2
Proc 3
72 / 220
Exemples (PVM et MPI) de communications point à point
I
Envoi/réception standard
I
I
I
Envoi synchrone:
I
I
I
pvm send/pvm recv: asynchrone bloquant
(pvm Nrecv : réception non-bloquante simple)
mpi send/mpi recv: bloquant (synchronisme dépend de
l’implémentation)
(mpi Isend/mpi Irecv : communication non-bloquante
générale)
Bloquant : mpi Ssend
Non-bloquant : mpi ISsend
Envoi bufferisé:
bloquant : mpi Bsend et non-bloquant : mpi IBsend
73 / 220
Communications non symétriques
I
PUT(data) : écriture directe dans la mémoire d’un autre
processus
I
GET(data) : lecture dans la mémoire d’un autre processeur
Proc 1
Proc 2
Put (data)
Proc 1
Proc 2
Mémoire locale
Mémoire locale
Get (data)
Proc2 ne fait pas de réception
Proc1 ne fait pas d’envoi
Attention aux problèmes de cohérence de données !!
74 / 220
Examples d’opérations collectives
I
Communications au sein d’un groupe de processus ou d’un
communicateur
I
Les appels collectifs sont bloquants mais ne constituent pas un
point de synchronisation fiable (comparable à une barrière).
I
Diffusion dans un groupe:
Broadcast (data, label, Groupe)
I
Somme des données distribuées sur un groupe de procs:
Reduce (SUM, ValeurSum, ValeurLoc, Groupe, Dest)
ValeurSum n’est disponible que sur le processus Dest.
I
Maximum de valeurs distibuées disponible sur chaque processus
AllReduce(MAX, ValeurMax, ValeurLoc, Groupe)
ValeurMax est disponible sur tous les processus du Groupe.
75 / 220
Commentaires sur les protocoles de communications
I
un protocole différent est souvent utilisé pour les messages
courts et les messages longs (ex. Cray T3E, SGI origin)
I
Protocole pour messages courts
1/ écriture dans le buffer interne des données envoyées.
2/ le processus envoyeur continue son travail (si envoi
asynchrone)
I
Protocole pour messages longs
1/ envoi d’une requête d’envoi au destinataire
2/ attente d’un message prêt à recevoir
3/ envoi effectif des données rangées dans l’espace utilisateur du
récepteur
76 / 220
Influence de la taille des buffers sur les Communications
asynchrones
A/ Taille (Message) < Buf_interne
B/ Taille(Message) > Buf_interne
Proc. Source
Proc. Destination
Asynch.−Non bloquant
(isend)
Proc. Source
Proc. Destination
irecv(User_buf, Ireq)
(isend)
buf_interne
Local copy
Réception bloquante
recv (User_buf)
User_buf
Attente message
wait(Ireq)
Message déjà dans User_buf
Transfer
(User_buf)
Temps
77 / 220
Communications asynchrones et surcoût MPI
Illustration sur un code de factorization de matrices creuses
(code disponible sous mumps.enseeiht.fr/)
recv standard
recv asynchrone
Application
MPI
VT_API
20%
40%
60%
80%
78 / 220
Communications asynchrones et performance
• Temps pour la factorisation LU
(Matrice creuse d’ordre 64838 avec 7Mega entrées, 8 procs d’un Cray
T3E):
type de réception
standard
asynchrone
∗
0
37.0
27.3
512
37.4
26.5
MPI buffer size (bytes)
1K 4K∗ 64K 512K
38.3 37.6 32.8
28.3
26.6 26.4 26.2
26.2
2Mega
26.4
26.4
Valeur par défaut sur le Cray T3E.
79 / 220
Remarques sur la taille des buffers systèmes
Changer la taille des buffers peut donc conduire à
I
Une modification de la performance
(temps attente, nombre de copies internes ...)
I
Des résultats faux
(causalité mal gérée)
I
De nouvelles situations d’interblocage
(codes basés sur des communications standards (mpi send et
mpi recv) )
tous les cas d’erreur correspondent à des programmes/algo. erronés
80 / 220
Qu’est-ce qui influence les performances ?
I
La distribution des données
I
L’équilibrage du travail sur les processus
I
Recouvrement des communications par les calculs
L’optimisation des communications :
I
I
I
I
I
choix du mode de communication
( point à point ? symétrique ? synchrone ? bufferisé ? bloquante
...)
Optimisation algorithmiques:
pipelining - blocage - envoi au plus tôt - prefetch . . .
exploitation des protocoles d’implémentation des communications
(et taille des buffers internes)
exploiter l’architecture du réseau (topologie, connexions
bidirectionnelles, fonctionnement de plusieurs canaux simultanés)
81 / 220
Outline
Description des standards pour la programmation en mode message
Distributed and heterogeneous computing using PVM
82 / 220
Description des standards pour la programmation en mode
message
83 / 220
Outline
84 / 220
I
Short overview of the PVM computing environment.
I
Simple example.
I
XPVM tracing tool used for illustration
I
Complete description of PVM : [2, 6, 3].
I
Many of the examples we use are coming from these references.
85 / 220
Overview of the PVM computing environment
PVM (Parallel Virtual Machine) :
I
Public domain software available on netlib
I
Developed by the Oak Ridge National Laboratory, the University
of Tennessee, the University of Carnegie Mellon, the Pittsburgh
Supercomputing Center and the Emory University of Atlanta.
I
Allows to use a network of heterogeneous UNIX computers
(either serial or parallel) as a unique computing resource referred
to as a virtual machine.
86 / 220
Workstation
Workstation
Fast network
Workstation
Workstation
Slow Network
Workstation
Mini−Comp
Super−Comp
Figure : Example of virtual machine
87 / 220
I
Daemon on each node of the virtual machine coordinates work
distributed on the virtual machine.
I
Host file : contains the list of computers and allows to
automatically activate the UNIX daemons and build the parallel
virtual machine at start-up.
I
Application viewed as a set of parallel processes (MIMD
programing mode) being executed on the processors of the
virtual machine
I
Communication and synchronization using message passing
I
Processes can be organized into groups (a process can belong to
several groups and groups can change at any time during
computation).
88 / 220
From the user point of view, the PVM package is composed of two
parts :
I
daemon process pvmd3: resides on each computer of the
parallel virtual machine. Can be started interactively or
automatically.
I
When user wants to run an application in the PVM environment:
I
I
I
pvmd3 starts a daemon on each node of a virtual machine
described in host file.
The application can then be started from any node.
pvm starts the PVM console used to interactively control and
modify the virtual machine both in terms of host nodes and
processes. pvm may be started and stopped multiple times on
any of the hosts.
89 / 220
I
set of library procedures: communication and synchronization
procedures used from C or FORTRAN.
I
I
I
I
I
Facilities to create and terminate processes,
to communicate between processes,
to synchronize processes,
to modify the parallel virtual machine,
and to manipulate process groups.
90 / 220
We focus on the main procedures of the PVM user library.
Complete version of PVM3 user library [6] available on netlib.
91 / 220
The PVM3 user library
Notations:
tid
ntask
tids()
bufid
msgtag
encoding
bytes
info
task
group
size
xp
stride
nitem
integer
integer
integer array
integer
integer
integer
integer
integer
character
character
integer
’what’
integer
integer
:
:
:
:
:
:
:
:
:
:
:
:
:
:
identifier of the PVM process
number of processes
array of PVM process identifiers
identifier of a buffer
message label
message coding
length of a message in bytes
erro message
name of an executable file
group identifier
size of the group
data array
stride between two elements
number of elements
Control of processes
Enroll a process in PVM
call pvmfmytid(tid)
At its first call, the pvmfmytid() procedure creates a PVM
process. pvmfmytid() returns the process identifier tid and may be
called several times. If the host node does not belong to the
parallel virtual machine then an error message is returned.
Leave PVM
call pvmfexit(info)
pvmfexit indicates to the local daemon (pvmd3) that the process
leaves the PVM environment. The process is not killed but it
cannot communicate (via PVM) with other PVM processes.
Kill another PVM process:
call pvmfkill(tid, info) pvmfkill kills the PVM process identified by
tid.
93 / 220
Activation of processes
Starting other processes on the virtual machine
call pvmfspawn(task, flag, where, ntask, tids, numt)
Starts ntask copies of executable file task. flag allows to control
the type of computer on which will be activated the processes.
Predefined values of flag :
PvmDefault PVM chooses the computers
PvmArch
where defines a target architecture.
PvmHost
where specifies a target computer.
PvmDebug
processes are activated in debugging mode.
numt → # processes actually activated. Task identifiers → first
numt positions of tids(ntask). Error codes (neg. values) → last
ntask-numt positions of tids().
Get tid of father: call pvmfparent(tid)
On exit tid → tid of parent process , otherwise tid set to negative
value PvmNoParent.
94 / 220
Fortran Example
SPMD programming mode
......
* Enroll task in PVM system
call pvmftid( mytid )
* Find out if I am parent or child *
All child processes have parents
call pvmfparent( tids( 0 ) )
if( tids( 0 ) .lt. 0 ) then
tids( 0 ) = mytid
me = 0
* Start up child tasks ( copies of parent task )
call pvmfspawn( ’spmd’, PVMDEFAULT, ’*’,
&
NPROC - 1, tids( 1 ), info )
endif
......
95 / 220
Interprocess communication
Communication between PVM processes based on message-passing.
PVM provides asynchronous send, blocking receive, and nonblocking
receive facilities.
Sending a message is done in three steps :
1. initialization of a send buffer and choice of an encoding format
to send data; (pvmfinitsend)
2. packing of data to be sent into the send buffer (pvmfpack);
3. actual send/broadcast of the message stored in the send buffer
to destination(s) process(es) (pvmfsend, pvmfcast).
96 / 220
Memory/data
Send buffer
pvmfpack
pvmfsend
Sending Process
Memory/data
Receive buffer
pvmfunpack
pvmfrecv
Receiving Process
Figure : Illustration of send/receive main steps
97 / 220
I
Main advantage of this strategy : user can compose his message
out of various pieces of data and therefore decrease the number
of messages effectively sent.
I
With the broadcast option, only one send buffer has to be filled.
I
If one large array of only a given data type needs to be sent
(pvmfpsend) has been designed to pack and send data in one
call to improve performance.
98 / 220
Reception is symmetric to the three step sending procedure After
reception of message into the active buffer, data are unpacked into
the destination arrays.
Various options to receive data are provided:
pvmfrecv
: blocking receive
pvmftrecv : timeout receive
pvmfnrecv : nonblocking receive
pvmprecv : combines blocking receive and unpacking.
99 / 220
Management of buffers
Clear/initialize send buffer
call pvmfinitsend( encoding, bufid)
clears the send buffer and prepare it for packing a new message.
Encoding scheme used during data packing defined by encoding.
Predefined values of encoding in FORTRAN:
PvmDefault The XDR encoding used
(heterogeneous network of computers).
PvmRaw
No encoding, native format of the host node.
PvmInPlace Data are not copied into the buffer which
only contains the size and pointers to the data.
Several buffers can be used simultaneously, but only one is active
buffer for sending/receiving data. Procedures to create/release
buffers (pvmfmkbuf, pvmffreebuf) to get/set the active send/receive
buffer (pvmfgetrbuf, pvmfgetsbuf, pvmfsetsbuf, pvmfsetrbuf) are
designed for this purpose.
100 / 220
Packing/unpacking data
call pvmfpack(what, xp, nitem, stride, info)
pvmfpack packs an array of data of a given type into the active
send buffer. A message containing data of different types may be
built using successive calls to pvmfpack. nitem elements chosen
each stride elements of the linear array xp of type what are packed
into the buffer.
Predefined values of what :
STRING, BYTE1, INTEGER2, INTEGER4
REAL4, REAL8, COMPLEX8, COMPLEX16
call pvmfunpack(what, xp, nitem, stride, info)
Similarly, pvmfunpack is used to unpack informations held into the
active receive buffer. The unpacked data are then stored into the
array xp.
101 / 220
Sending messages
Send : call pvmfsend(tid, msgtag, info)
pvmfsend sets the message label to msgtag then sends it to the
pvm process of number tid.
Broadcast : call pvmfmcast(ntask, tids, msgtag, info)
pvmfmcast broadcast the message to ntask processes specified
into the integer array tids.
Pack and send :
call pvmfpsend (tid, msgtag, xp, nitem, type, info)
102 / 220
Receiving Messages
Blocking receive
call pvmfrecv( tid, mstag, bufid )
Non Blocking Receive
call pvmfnrecv( tid, mstag, bufid )
( bufid = 0 ≡ message not received )
Wildcards
tid = -1 any message message tag mstag.
mstag = -1 any message message from tid.
tid = -1 and mstag = -1 any message.
103 / 220
Receive and unpack
call pvmfprecv(tid,msgtag,xp,nitem,type,rtid,rtag,ritem,info)
Check for arrived messages
call pvmfprobe(tid, msgtag, bufid)
If the message is not arrived then bufid =0, otherwise a buffer
number is returned but the message is not received.
A posteriori verification call pvmfbufinfo(bufid, bytes, msgtag,
tid, info)
pvmfbufinfo returns the characteristics of the message stored in
bufid: label msgtag, sending process tid, length in bytes bytes.
pvmfbufinfo is particularly useful in conjunction with pvmfprobe or
when the label –or the source– of the message to be received have
not been specified.
104 / 220
Sequential code
Parallel Approach
Do It = Ibeg, Ifin
(subdive the image)
Update image
(1)
(2)
(3)
(4)
Print image
Enddo
(1)
(2)
(3)
(4)
(4)
(1)
(3)
(2)
Master task
( Build a complete image at each iteration )
Slave task ( i )
Do It = Ibeg, Ifin
( Update image ( i ); Pack in active buffer )
call pvmfsend(tid_master, It, info)
Enddo
Do It = Ibeg, Ifin
Do Idummy= 1, Nb_slaves
call pvmfrecv ( −1, It, bufid)
( bufinfo −−> tids (Islave) )
( Unpack and Assemble image Islave )
Enddo
( Print full image )
Enddo
* SPMD Fortran example using PVM 3
* Enroll in pvm
call pvmfmytid( mytid )
call pvmfparent( tids( 0 ) )
if( tids( 0 ) .lt. 0 ) then
tids( 0 ) = mytid; me = 0
call pvmfspawn(’spmd’,PVMDEFAULT,’*’,NPROC-1,
tids( 1 ), info )
*
multicast tids array to children
call pvmfinitsend( PVMDEFAULT, info )
call pvmfpack( INTEGER4, tids( 1 ), NPROC-1, 1, info )
call pvmfmcast(NPROC-1,tids(1),msgt0,info)
else
*
receive the tids of brothers and identify
call pvmfrecv( tids( 0 ), msgt0, info )
call pvmfunpack( INTEGER4, tids(1),NPROC-1,1,info)
do i = 1, NPROC-1
if( mytid .eq. tids( i ) ) me = i
enddo
endif
call dowork(me,tids,NPROC )
call pvmfexit( info )
stop
end
106 / 220
s u b r o u t i n e dowork ( me , t i d s , n p r o c )
i n c l u d e ’ ??/ i n c l u d e / fpvm3 . h ’
∗ S i m p l e s u b r o u t i n e to p a s s a t o k e n a r o u n d a r i n g
i n t e g e r me , nproc , t i d s ( 0 : n p r o c )
i n t e g e r token , d e s t , count , s t r i d e , msgtag
c o u n t = 1 ; s t r i d e = 1 ; msgtag = 4
i f ( me . eq . 0 ) then
token = t i d s ( 0 )
c a l l pvmf i n i t s e n d ( PVMDEFAULT, i n f o )
c a l l pvmf pack ( INTEGER4 , token , count , s t r i d e , i n f o )
c a l l pvmf s e n d ( t i d s ( me + 1 ) , msgtag , i n f o )
c a l l pvmf r e c v ( t i d s ( n p r o c − 1 ) , msgtag , i n f o )
else
c a l l pvmf r e c v ( t i d s ( me − 1 ) , msgtag , i n f o )
c a l l pvmf unpack ( INTEGER4 , token , count , s t r i d e , i n f o )
c a l l pvmf i n i t s e n d ( PVMDEFAULT, i n f o )
c a l l pvmf pack ( INTEGER4 , token , count , s t r i d e , i n f o )
d e s t = t i d s ( me + 1 )
i f ( me . eq . nproc −1 ) d e s t = t i d s ( 0 )
c a l l { pvmfsend } ( d e s t , msgtag , i n f o )
endif
return
107 / 220
Management of process groups
Procedures to manage process groups form a layer on top of the
PVM layer (library libgpvm3.a).
Main characteristics of PVM groups:
• Any PVM process can join pvmfjoingroup and pvmfleave a
group;
• A process can belong to several groups;
• A message can be broadcasted to a PVM group from any PVM
process pvmfbcast
• Synchronization within a group can be performed using barriers
pvmfbarrier.
• Useful procedures: pvmfgettid, pvmfgetinst pvmfgsize, . . .
PVM 3.3 provides collective communication routines such as
pvmfreduce() that performs a global arithmetic operations (e.g.
global maximum or global sum) across a group. Must be called by all
processes in the group, final result is sent to a member specified as
root.
There is also a way of managing with system signals.
108 / 220
Illustrative Example: a dot version of the matrix vector
product
I
I
Straightforward static parallelization of the matrix-vector
product,
y = A×x
where A is a (m × n) matrix, x an n-vector, and y an m-vector.
Master-slave paradigm: Each process is in charge of computing
one block y . Additionally master process broadcasts the data to
the slaves and collects the final results.
The sequential FORTRAN code is:
do i = 1 ,
y( i ) =
do j =
y( i )
enddo
enddo
m
0 . 0 D0
1, n
= y ( i ) + A( i , j ) ∗ x ( j )
109 / 220
In the parallel implementation,
master
x
A
x
slave 1
x
first_row(1)
first_row(2)
first_row(3)
slave 2
x
slave 3
x
Figure : Static parallelization of the matrix vector product: A partitioned
into block of rows distributed on the slave processes.
110 / 220
• Master process
• Slave process
(the master holds A and x)
enroll into PVM
enroll into PVM
create slaves
send data to slaves
recv data from master
compute part of y
compute my block of y
receive results
send back results
leave PVM application
leave PVM application
Computation of one block of y is performed using GEMV from the
Level 2 BLAS (see [4]) which performs:
y = α A x + βy
111 / 220
Codes for master and slave processes
Master’s code:
*
* Enroll this program in Pvm
call pvmfmytid (my_id)
if (my_id .lt. 0) then
write(*,*) ’failure in enrolling on host’
stop
endif
write(*,*) ’ How many slave worstations will you used ’
read(*,*) nb_of_slaves
* Initiate nb_of_slaves instances of slave program
call pvmfspawn (’slave’,PVMDEFAULT,’*’,
&
nb_of_slaves,inst,numt)
* Check if everything is Ok
if (numt .ne. nb_of_slaves) stop
112 / 220
*
*
*
nb_of_processes = nb_of_slaves +1
do j=1,n
do i = 1,m
a(i,j) = DBLE(i+j)/DBLE(m+n) + one
enddo
x(j) = one + DBLE(j)/DBLE(n)
enddo
compute the index of the first row
performed by each process
first_row(1)
= 1
first_row(nb_of_processes+1) = m+1
j = (m / nb_of_processes)
if (nb_of_slaves.gt.0) then
do i=2,nb_of_processes
first_row(i) = j*(i-1) +1
enddo
work balancing
j = mod(m,nb_of_processes)
do i=1, j-1
first_row(nb_of_processes-i+1) =
&
first_row(nb_of_processes-i+1) +j -i
enddo
113 / 220
* broadcast n and x
type = 0
call pvmfinitsend ( PVMDATADEFAULT, bufidS)
call pvmfpack (INTEGER4, n, 1, 1, info)
call pvmfpack (REAL8,
x, n, 1, info)
call pvmfmcast (nb_of_slaves, inst, type, info)
* send its sub-matrix data to each slave process
type = 1
do no_slave = 1, nb_of_processes-1
*
number of components computed by the slave no_slave
j = first_row(no_slave+2) - first_row(no_slave+1)
call pvmfpack (INTEGER4, j, 1, 1, info)
call pvmfsend (inst(no_slave), type, info)
do i=1, n
call pvmfpack (REAL8,
&
a(first_row(no_slave+1),i),j,1,info)
call pvmfsend (inst(no_slave), type, info)
enddo
enddo
114 / 220
*
*
*
*
*
*
*
*
*
-----------------------------------compute its part of the work
-----------------------------------perform y <-- one*Ax + zero*y
where A is an matrix of order (first_row(1)-1) x n.
incx = 1
call dgemv(’N’,first_row(1)-1,n,one,a,lda,x,
&
incx,zero,y,incx)
---------------------collect results
---------------------type = 2
do no_slave = 1, nb_of_slaves
j holds number of rows computed by no_slave
j = first_row(no_slave+2) - first_row(no_slave+1)
call pvmfrecv (inst(no_slave), type, bufidR)
call pvmfunpack (REAL8,
&
y(first_row(no_slave+1)),j,1,info)
enddo
call pvmfexit(retcode)
stop
end
115 / 220
Slave’s code:
PROGRAM slave
...
double precision a(lda,lda),x(lda),y(lda),one,zero
* Enroll this program in PVM˙3
call pvmfmytid (my_id)
* Get the tid of the master’s task id
call pvmfparent (p_id)
* receive broadcasted data
type = 0
call pvmfrecv (p_id, type, bufid)
call pvmfunpack (INTEGER4, n, 1, 1, info)
call pvmfunpack (REAL8
, x, n, 1, info)
* receive my block of rows
type = 1
call pvmfrecv (p_id, type, bufidR)
call pvmfunpack (INTEGER4, m, 1, 1, info)
do 10, i=1,n
call pvmfrecv (p_id, type, bufidR)
call pvmfunpack (REAL8, a(1,i), m, 1, info)
10
continue
116 / 220
*
perform matrix-vector on my block of rows
incx = 1
call dgemv(’N’,m,n,one,a,lda,x,incx,zero,y,incx)
*
send back results to master process
type = 2
call pvmfinitsend (PVMDATADEFAULT, bufid)
call pvmfpack (REAL8, y, m, 1, info)
call pvmfsend (p_id, type, info)
* leave PVM environment
call pvmfexit (info)
stop
end
117 / 220
Makefile for Compilation - Link
PvmArch and PvmDir correspond respectively to target computer
and to location of the PVM library.
F77
= /usr/lang/f77
FOPTS = -O -u
# Specification of the target computer
PvmArch
=
SUN4
# Location of PVM libraries
PvmDir
=
/usr/local/pvm3/lib
# PVM libraries (C, FORTRAN, Group)
PVMLIB_C =
$(PvmDir)/$(PvmArch)/libpvm3.a
PVMLIB_F =
$(PvmDir)/$(PvmArch)/libfpvm3.a
PVMLIB_G =
$(PvmDir)/$(PvmArch)/libgpvm3.a
LIBS
=
$(PVMLIB_F) $(PVMLIB_C) $(PVMLIB_G)
# Location of the executable files
IDIR
= $(HOME)/pvm3/bin/$(PvmArch)
all : dotmatvec slave
dotmatvec : master.o $(BLAS) $(TIMING)
$(F77) -o dotmatvec master.o $(LIBS) -lblas
mv dotmatvec $(IDIR)
slave : slave.o $(BLAS)
$(F77) -o slave slave.o $(LIBS) -lblas
mv slave $(IDIR)
.f.o :
$(F77) $(FOPTS) -c $*.f
clean :
/bin/rm *.o
118 / 220
Configuration of the virtual machine
I
Configuration file describe the list of computers used.
I
Used to start the pvmd3 daemon on each computer listed.
I
Parallel Virtual Machine can be controled using the pvm console.
I
Other solution use directly the pvm console to build the virtual
machine.
I
Both solutions illustrated in the following example : a parallel
virtual machine of 4 RISC workstations (HP, IBM and two SUN)
is build. The HP workstation, pie, is our host computer.
119 / 220
Example
pie> cat hostfile
# comments
pie
pinson
goeland
aigle
pie> pvmd3 hostfile &
pie> pvm
> conf
4 hosts, 1 data format
HOST
DTID
pie
40000
pinson
80000
goeland
c0000
aigle
100000
pie> pvm
pvm> conf
1 host, 1 data format
HOST
DTID
pie
40000
pvm> add pinson goeland aigle
3 successful
HOST
DTID
pinson
80000
goeland
c0000
aigle
100000
ARCH
HPPA
SUN4
RS6K
SUN4
SPEED
1000
1000
1000
1000
ARCH
HPPA
SPEED
1000
120 / 220
Performance analysis and graphical interface
I
I
I
I
I
I
I
Analysis of the efficiency of the parallel execution of a program
complex problem by itself.
Time measures and speed-up estimations often not sufficient to
understand the behaviour of a parallel application.
Automatic tracing of parallel execution → indispensable tool
both to visualize the parallel behaviour and to debug.
PVM allows to control which events are generated and where
messages will be sent → quite complex to use.
XPVM: tracing tool exploiting automatically features of PVM.
PVM’s tracing facilities generate extra traffic in the network →
will perturb program execution.
We show traces obtained during parallel execution of
matrix-vector product. Target vitual machine = heterogeneous
set of 4 RISC workstations. Master process located on computer
node rosanna.
121 / 220
Figure : XPVM trace of the static parallelisation of the matrix-vector
product
Note that the fastest computer (sharon) is idle most of the time.
122 / 220
Outline
123 / 220
1. Effort de définition d’un standard de transfert de message pour
les utilisateurs de développeurs
2. Juin 94 Version 1.0 issue du forum MPI Message Passing
Interface [12, 5]
3. Objectifs :
I
I
I
portabilité, simplicité
utilisation plus large du calcul distribué
implantation par les constructeurs
4. Pour multiprocesseurs, clusters et réseaux de calculateurs
Accessible sur le site netlib ou sur le Web, voir par exemple :
http://www.enseeiht.fr or http://www.netlib.org
Versions publiques disponibles: LAM (Univ. Notre Dame), MPICH
(Argonne Nat. Lab.), OpenMPI (www.open-mpi.org).
124 / 220
Notions basiques
I
Groupe de processus MPI
I
Contexte : pour définir des flots de messages indépendants.
I
Communicateur: permet de définir un contexte de
communication au sein d’un groupe de processus.
I
Message : contexte et un numéro de message/contexte
I
4 modes de communication : bloquants, non-bloquants,
synchrones, bufferisés.
I
Communication collectives et définition de sous-groupes
I
Modèle de programmation SPMD, 125 fonctions dont 6 de
base : MPI Init, MPI Finalize, MPI Comm size,
MPI Comm rank, MPI Send, MPI Recv
125 / 220
Environnement
I
enregistrement : call MPI Init( info )
I
terminaison : call MPI Finalize
I
contexte par défaut : MPI COMM WORLD : tâches numérotées
0, . . . , N-1
I
création de nouveaux contextes : définir des nouveaux groupes
de processus et un nouveau contexte
126 / 220
Example : Hello world
#i n c l u d e ” mpi . h”
#i n c l u d e < s t d i o . h>
i n t main ( a r g c , a r g v )
int argc ;
char ∗∗ a r g v ;
{ i n t rank , s i z e
M P I I n i t ( &a r g c , &a r g v ) ;
MPI Comm rank ( MPI COMM WORLD, &r a n k ) ;
MPI Comm size ( MPI COMM WORLD, & s i z e ) ;
p r i n t f ( ” H e l l o w o r l d ! I ’m %d o f %d\n” , rank , s i z e ) ;
MPI Finalize ();
return 0: }
Exécution sous MPICH avec : mpirun -np 2 hello
printf exécuté par 2 processus.
127 / 220
Envoi / réception message : opérations de base
I
Envoi/Réception de données de type datatype rangées à @ :
I
I
call MPI Send ( @, nb, datatype, dest, mess id, comm,info)
call MPI Recv ( @, nb, datatype, source, mess id, comm, status,
info )
I
Diffusion: toutes les tâches émettent la requète; les données
sont envoyées par le processus root:
call MPI Bcast ( @,nb,datatype,root,mess id,context,info)
I
Opération collective: Le processus root reçoit les résultats:
call MPI Reduce ( @, results, nb, datatype, operation, root,
context, info )
datatype peut être prédéfini (MPI real) ou défini par l’utilisateur;
context définit le groupe de tâches et le contexte
128 / 220
Les modes de communication point à point
Bloquant L’émetteur est bloqué jusqu’à ce que la donnée envoyée
puisse être réutilisée en toute sécurité.
Synchrone Le retour d’un envoi synchrone indique que la donnée
envoyée a commencé à etre reçue par le récepteur.
Bufferisé Le retour d’un envoi bufferisé indique que la donnée a été
copiée dans le buffer.
Ready L’envoi n’est possible que si le destinataire a déjà posté une
reception
129 / 220
Sémantique des communications point à point
I
MPI Send et MPI Recv: Asynchrone et Bloquant;
L’émetteur est bloqué jusqu’à ce que la donnée envoyée puisse
être réutilisée en toute sécurité.
130 / 220
I
I
MPI Bsend: Bufferisé, Asynchrone, et Bloquant;
L’utilisateur définit un buffer
(MPI Buffer Attach/Detach(buffer, size). L’envoyeur est
bloqué jusqu’a ce que la donnée envoyée ait été copiée dans le
buffer (erreur si buffer plein/petit).
131 / 220
I
I
I
MPI Isend, MPI Irecv: Asynchrone et Non bloquant;
En retour, la donnée envoyée ne doit pas être modifiée.
MPI Wait, MPI Test pour gérer les données.
132 / 220
I
I
I
I
MPI Ssend, MPI Srecv : Synchrone (rendez-vous);
Le retour de MPI Ssend indique que la donnée envoyée est
réutilisable ET que le recepteur a commencé à recevoir.
133 / 220
I
I
I
I
I
MPI Ssend, MPI Srecv : Synchrone (rendez-vous);
Le retour de MPI Ssend indique que la donnée envoyée est
réutilisable ET que le recepteur a commencé à recevoir.
MPI Rsend : Ready et bloquant;
L’envoi bloquant n’est possible que si le destinataire a déjà posté
une reception (sinon erreur).
134 / 220
Attente ou test de messages
MPI Probe (Source, label, comm, status): Attend l’arrivée d’un
message (source,label) mais ne le reçoit pas.
MPI IProbe (Source, label, comm, status): Regarde si message
disponible
MPI Any Source,MPI Any Tag : n’importe quel source ou label
Associé à une requête non bloquante
(par ex MPI ISend/MPI IRecv):
MPI Wait (Request) : Attente
MPI Test (Request) : Test
MPI Cancel (Request) : Nettoyage, utilisation parfois délicate.
135 / 220
Exercice 1: communications point à point
I
En supposant que I = non-bloquant, S=synchrone,
R=ReadyMode, déduire la sémantique des primitives MPI
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
136 / 220
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
Retour immédiat si le destinataire a déjà posté une réception
sinon erreur de retour (pour le reste idem MPI Isend).
137 / 220
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
138 / 220
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
Retour immédiat. Le S de ISsend : la fin de l’envoi (obtenue par
ex. après un MPI Wait(Ireq)) garantit que le récepteur est en
train de recevoir l’information. Ce n’est pas le cas avec un
MPI wait consécutif à un MPI ISend. Par contre rien ne garantit
que la communication soit finie.
139 / 220
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
3. MPI IBsend ( . . . , Ireq, . . . )
140 / 220
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
3. MPI IBsend ( . . . , Ireq, . . . ) Retour immédiat. Le B de IBsend
: la fin de l’envoi (obtenue par ex. après un MPI Wait(Ireq))
garantit que le message est bufferisé mais ne garantit pas qu’il ait
été envoyé. (cas d’erreur: le buffer est trop petit).
141 / 220
Exercice 2: Communications point à point
I
Commenter le comportement du programme suivant (exécuté
sur 2 processus):
CALL MPI COMM RANK(comm , rank , i e r r )
tag = 1
IF ( r a n k . EQ . 0 ) THEN
dest = 1
ELSE
dest = 0
ENDIF
CALL MPI Send ( SData , count , MPI REAL , d e s t , tag , comm , i e r r )
CALL MPI Recv ( RData , count , MPI REAL , d e s t , tag , comm , i e r r )
142 / 220
I
sur 2 processus):
tag = 1
dest = 1
ELSE
dest = 0
ENDIF
Le message envoyé doit être copié pour que l’envoi se débloque.
Le programme ne peut donc se finir que si au moins un des deux
messages est copié dans un buffer interne local
143 / 220
I
sur 2 processus):
tag = 1
dest = 1
ELSE
dest = 0
ENDIF
Le message envoyé doit être copié pour que l’envoi se débloque.
Le programme ne peut donc se finir que si au moins un des deux
messages est copié dans un buffer interne local
Pour des messages de grande taille cela peut donc entraı̂ner un
interblocage des processus
144 / 220
Communication glogales
I
Barrières MPI Barrier (communicateur) : bloque l’appelant
jusqu’à ce que tous les proc membres du communicateur aient
effectués l’appel.
I
Broadcast MPI Bcast
I
réduction disponible sur un proc ou sur tous
MPI Reduce/MPI Allreduce: max global, somme globale, . . .
I
scatter / gather, all to all
145 / 220
Communications persistantes-Illustration
Cas de communications effectuées en boucle dans un programme
1. Initialisation(s) d’envoi(s)/réception(s):
MPI xSend Init ( ..., Req ) / MPI xRecv Init ( Req )
Possibilité de faire de multiples initialisations
2. Lancement effectif dans la boucle
MPI Start ( Req )
3. Attente de requêtes (multiples) dans la boucle:
MPI Wait, MPI Wait All, MPI Wait Some
MPI Test, MPI Test All, MPI Test Some
All = attente fin de toutes les requêtes mentionnées à l’appel
Some = au moins une a fini (out: liste des requêtes finies)
Any = attendre la fin d’une requête choisie parmi toutes celles
finies (out: une requête finie)
(utilisable bien sûr aussi avec des requêtes non bloquantes
classiques)
146 / 220
Exercice: Recouvrir calcul et communications
Soit le programme suivant:
p r e v = rank −1; n e x t = r a n k+1
IF ( r a n k . EQ . N p r o c s ) n e x t = 0
IF ( r a n k . EQ. 0
) p r e v = n p r o c s −1
CALL MPI Send ( SData , count , MPI REAL , n e x t , tag , comm , i e r r )
CALL C a l c u l ( r a n k ) ! Rdata and S d a t a n o t u s e d i n C a l c u l
CALL MPI Recv ( RData , count , MPI REAL , p r e c , tag , comm , i e r r )
ELSE
ENDIF
Hypothèses :
I Protocole long (synchrone) pour messages longs.
I Si l’émetteur est occupé (sans appel MPI) la communication ne
peut démarrer. Un timeout (MPI) est souvent associé à la notion
de calcul non interruptible.
147 / 220
Exercice: Recouvrir calcul et communications (suite)
CALL MPI Send ( SData , count , MPI REAL , d e s t
CALL C a l c u l ( r a n k ) ! Rdata n o t u s e d i n
CALL MPI Recv ( RData , count , MPI REAL , d e s t
ELSE
CALL MPI Recv ( RData , count , MPI REAL , d e s t
CALL MPI Send ( SData , count , MPI REAL , d e s t
CALL C a l c u l ( r a n k ) ! Rdata n o t u s e d i n
ENDIF
, tag , comm , i e r r )
Calcul
Calcul
On suppose Nprocs=3; Sdata de grande taille (temps de comm
50sec); Temps de Calcul(rank)= (200, 150, 150)sec.
1. Calculer le temps d’exécution.
2. Pour recouvrir calcul et communications on propose de
remplacer MPI Send par un appel non-bloquant MPI ISend.
I
Calculer le temps d’exécution.
3. Comment réduire le temps d’exécution ?
148 / 220
Solution (I)
CALL C a l c u l ( r a n k ) ! Rdata and S d a t a n o t u s e d i n c a l c u l
ELSE
ENDIF
1. MPI Send: Temps
= Max(50+200+50, 50+150+50, (100+150+50+150) = 450 sec
Le fait que la reception n’ait pas été postée plus tôt par P0 est
une catastrophe !
2. MPI ISend: Temps = 200 + 50 + 150 + 50 + 150 + 50 = 650 sec;
On a en plus perdu le recouvrement entre le calcul de PO et de P1
!!
149 / 220
Solution (II) avec modification Recv sur proc0
CALL M P I I r e c v ( RData , count , MPI REAL , p r e c , tag , comm , I r e q , i e r r )
CALL C a l c u l ( r a n k ) ! Rdata n o t u s e d i n c a l c u l
CALL MPI Wait ( I r e q )
ELSE
CALL C a l c u l ( r a n k ) ! Rdata n o t u s e d i n C a l c u l
ENDIF
Influence du type d’envoi:
MPI send: Temps= max(50 + 200, 100 + 150, 150 + 150) = 300sec
MPI Isend: Temps = 200 + 50 + 150 + 50 + 150 = 600 sec !!!
MPI Ssend Temps= 300 sec (plus robuste que MPI Send)
MPI ISsend: Idem MPI Isend
MPI ISsend(Ireq)+MPI Wait(Ireq): Idem MPI Ssend
Bricole: Ajouter des MPI Bidon dans calcul ou réduire le paramètre
MPI du timeout
150 / 220
MPI: remarques conclusives
I
Très grande richesse pour exprimer la communication (point à
point, collective)
I
La sémantique de MPI Send/Recv doit être respectée (risque
d’interblocage)
Ajouts de MPI-2 vis à vis de MPI-1
I
I
I
I
I
I
Gestion dynamique des proc (MPI Comm Spawn, idem PVM)
plus extensions pour fusionner les communicateurs
((MPI Intercomm Merge).
IO parallèle (bloquante ou non, collective ou non)
Communications mémoire à mémoire (PUT/GET)
Interaction avec threads
Disponibles dans OpenMPI et LAM mais pas encore chez tous les
constructeurs (dont IBM).
151 / 220
Outline
Analyse de performance et modélisation des algorithmes
Terminologie
Exemples d’outils pour l’analyse de performances
Modélisation de Hockney et Jesshope
Les modèles utilisés
Exemple d’analyse de performance d’algorithmes : Produit
Matrice-Vecteur
152 / 220
1. Evaluation des performances d’un algorithme =⇒ l’utilisation
de modèles pour :
1.1 Caractériser la machine cible
I
I
I
I
I
Le processeur
(Unités de calcul et d’accès mémoire, fréquence d’horloge, degré
de parallélisme interne ... )
Hiérarchie mémoire
(registres, cache, mémoire locale, globale, disque ...)
Réseau d’interconnection entre modules mémoires et processeurs.
Temps d’accès aux couches mémoires
(incluant les Entrées/Sorties sur disque)
Coûts de communication/synchronisation
153 / 220
1. l’algorithme
I
I
I
I
Objectif : représenter le parallélisme intrinsèque de l’algorithme,
Graphes de dépendance des calculs,
Graphe de flot de données,
Ces graphes peuvent être valués et orientés.
2. l’exécution du programme
I
I
I
Objectif : Analyse et classification a priori d’un algorithme.
Comment : simuler l’exécution du programme (de son modèle)
sur la machine cible (un modèle simplifié).
Un modèle d’exécution est donc caractérisé par les hypothèses
effectuées:
2.1 nombre borné ou infini de processeurs.
2.2 mémoire (globale, distribuée, infinie ..)
2.3 stratégie d’allocation des tâches sur les processeurs.
154 / 220
L’analyse des performances réelles
I
I
Permet la validation des modèles précédents.
Souvent difficile pour un code parallèle :
1. Choix de l’unité de mesure ?
2. influence de la taille du problème, architecture, charge du système
sur la mesure ?
I
Utilisation d’analyseurs automatiques de traces d’exécution
souvent indispensable.
155 / 220
Outline
Terminologie
Matrice-Vecteur
156 / 220
Terminologie
I
I
Problème: taille N exécuté sur p processeurs.
Vitesse: Nombre d’opérations par secondes
I
I
Flops: Opérations en virgule flottante par secondes
(Mflops(106 ), Gflops(109 ), Teraflops(1012 ))
Mips: Millions d’instructions élémentaires par secondes.
(1 flops −→ k instruc. de base)
I
Temps d’exécution séquentielle: T1 (N) = Ts (N) + Tpar (N)
I
Temps d’exécution parallèle: Tp (N, p)
I
Temps de surcoût parallèle Tsc (N, p) (communication,
synchronisation ...)
Tp (N, p) = Ts (N) +
Tpar (N)
+ Tsc (N, p)
p
157 / 220
I
Accélération (speed-up):
Sp (N, p) =
I
I
T1 (N)
Tp (N, p)
Sp > 1 =⇒ speed-up ; et Sp (N, p) < 1 =⇒ speed-down
Sp (N, p) > p =⇒speed-up superlinéaire.
(meilleure utilisation des hiérarchies mémoires, meilleur
comportement de l’algorithme parallèle)
158 / 220
100
Ts=Tsc=0
Ts>0, Tsc=0
10
Speedup
Ts>0, Tsc>0
1
1
10
100
1000
10000
Nb Processeurs
Figure : 3 comportements extrêmes
159 / 220
I
I
Si Tsc = 0 alors
Sp =
Ts + Tpar
Ts +
Tpar
p
donc S∞ = limp→∞ Sp = T1 /Ts ,
S∞ = 1 + Tpar /Ts
soit p 12 = Tpar (N)/Ts (N) alors:
Sp =
S∞
(1 + p 21 /p)
Remarques:
1. p 1 ∈ [0, ∞] et correspond au poids relatif de la partie //
2
(= 0 pas de //, = ∞ tout //).
2. p = p 1 =⇒ Sp = S∞
2
2
p 1 correspond au nombre de processeurs pour atteindre la moitié
2
de S∞ .
3. Si p ≥ 4p 1 alors 80% de S∞ est déjà atteint.
2
160 / 220
I
I
Si Tsc > 0 alors
Posons, par exemple: Tsc = αp alors
Sp =
1+
p1
2
p
S
∞ 2
p
1 + popt
p
où popt = Tpar /α et correspond au speed-up maximum Sopt .
Exemple: Tp = 1 + 10
p + 0.001p =⇒ Sopt = 9.17
I
Efficacité:
Ep (N, p) =
Sp (N, p)
p
1. Pour N fixé, si Tsc est une fonction croissante de p alors Ep
décroit avec p
2. Pour p fixé et Ts = 0, si Tsc croı̂t moins vite que T1 alors
Ep augmente avec N
161 / 220
I
Scalabilité:
Capacité à conserver Ep (N, p) constante lorsque p augmente.
T1 (N) doit augmenter de façon exponentielle =⇒ le sytème
est dit peu scalable.
T1 (N) doit augmenter linéairement =⇒ le sytème est
scalable.
I
Isoefficacité:
Mesure de scalabilité d’un algorithme parallèle, elle relie la taille
du problème au nombre de processeurs nécessaires pour
maintenir Ep = cte ou Sp croissant linéairement avec p.
1. On cherche le polynome d’ordre m, m ≥ 1 tel que
E (p, N) = E (kp, am N m + ... + a1 N + a0)
2. Plus m est petit plus le système est scalable.
162 / 220
I
Granularité:
Designe le volume de calcul effectué entre deux points de
synchronisation.
I
Equilibrage ou “load balancing”
Un calcul parallèle est équilibré si chaque processeur a à peu près
la même quantité de travail à effectuer.
163 / 220
Loi d’Amdahl pour le calcul parallèle (loi de Ware)
RAPPEL
I
Soit le programme P.
I
T1 : temps d’exécution de P sur 1 processeur
I
f : fraction de P pouvant être exécutée sur p processeurs
I
1 − f : zone séquentielle de P
I
Tp : temps d’exécution de P sur p processeurs
I
Tp = temps d’exéc. Séq. + temps d’exéc. Par.
I
temps d’exéc. Séq. = (1 − f )T1
I
temps d’exéc. Par. =
I
Tp = (1 − f ) × T1 +
f ×T1
p
f ×T1
et
p
Sp =
T1
Tp
164 / 220
I
Speed-up théorique avec p processeurs : Sp =
I
De façon plus réaliste :
Tp ≤
p
f +(1−f )×p
(f + (1 − f ) × p) × T1
(f + (1 − f ) × p) × T1
ou Tp =
+O
p
p
O overhead prenant en compte :
I
I
I
I
overheads de synchronisation
transferts de données (archi. mém. distribuée)
contentions mémoire
...
p
f +(1−f )p
I
MAIS quel que soit O : Sp ≤
I
Pour un nombre infini de processeurs : Speed-up maximum
S∞ ≤
1
1−f
165 / 220
Table : A very optimistic table
f
1.00
0.99
0.98
0.96
0.92
0.90
0.80
0.70
2
2
1.98
1.96
1.92
1.85
1.82
1.67
1.54
3
3
2.94
2.88
2.78
2.59
2.50
2.14
1.88
Number of processors p
4
8
16
32
4
8
16
32
3.88 7.48 13.91 24.43
3.77 7.02 12.31 19.75
3.57 6.25 10.00 14.29
3.23 5.13 7.27
9.19
3.08 4.71 6.40
7.80
2.50 3.33 4.00
4.44
2.11 2.58 2.91
3.11
64
64
39.26
28.32
18.18
10.60
8.77
4.71
3.22
∞
∞
100
50
25
12.50
10.00
5.00
3.33
166 / 220
Outline
Terminologie
Matrice-Vecteur
167 / 220
168 / 220
Profiling automatique
Objectif :
Etude du temps passé dans les unités de programme : en général
procédures/fonctions, mais aussi parfois boucles et intructions.
1. exemple : gprof sous UNIX permet d’étudier le temps passé par
procédure.
1.1 Compilation des sources avec options appropriées (habituellement
-pg ou -p)
1.2 L’exécution produit un fichier gmon.out
1.3 Postraitement, avec options multiples, du fichier gmon.out:
gprof [options] nom executable > fichier profile
169 / 220
Exemple de fichier profile obtenu :
%
cumulative
time
seconds
98.6
218.79
0.7
220.39
0.6
221.63
0.1
221.87
....
self
seconds
218.79
1.60
1.24
0.24
self
total
calls ms/call ms/call name
1 218790.00 218790.0 _matmul_ [3]
5
320.00
320.0 _matsum_ [4]
1 1240.00 221880.0 _MAIN__ [1]
1
240.00
240.0 _matvec_ [5]
170 / 220
La seconde partie du fichier profile permet d’identifier l’arbre d’appel
(parents et descendants) de chaque routine.
called/total
called+self
called/total
1.24
220.64
1/1
[1]
100.0
1.24
220.64
1
218.79
0.00
1/1
1.60
0.00
5/5
0.24
0.00
1/1
----------------------------------------------[2]
100.0
0.00
221.88
1.24
220.64
1/1
0.00
0.00
1/2
----------------------------------------------218.79
0.00
1/1
[3]
98.6 218.79
0.00
1
----------------------------------------------1.60
0.00
5/5
[4]
0.7
1.60
0.00
5
----------------------------------------------0.24
0.00
1/1
[5]
0.1
0.24
0.00
1
----------------------------------------------...
index
%time
self descendents
parents
name
index
children
_main [2]
_MAIN__ [1]
_matmul_ [3]
_matsum_ [4]
_matvec_ [5]
_main [2]
_MAIN__ [1]
_getenv [49]
_MAIN__ [1]
_matmul_ [3]
_MAIN__ [1]
_matsum_ [4]
_MAIN__ [1]
_matvec_ [5]
171 / 220
Analyse automatiques de la performance et des cache-hits sur CRAY
T3D (code de mécanique des fluides):
secs
Mflops
data caches time
PVMFRECV:11400
gradvelo: 672
7.58
82.89%
infl3dc : 602
5.03
76.71%
gradvel : 202
8.31
81.29%
grad3d : 322
5.94
76.06%
nufl3dc : 414
5.82
55.76%
PVMFSEND: 635
SQRT
: 320
vsfl3dc : 217
9.09
80.07%
ns3dc
: 256
2.50
81.91%
implrssm: 177
7.59
57.58%
edvialg : 139
3.86
49.22%
shearstr:
52
15.89
78.34%
dtvis3dc: 127
6.79
68.03%
updpct :
83.5
6.55
84.15%
heatflpg:
45.0
6.39
70.70%
EXP
:
53.7
Total code:
12100 secs
969 ( 6.07%) work
2514 (15.76%) loading instructions and data cache
12061 (75.59%) waiting on PVM communication
411 ( 2.58%) uninstrumented functions
172 / 220
Analyse de performance des boucles
I
I
Traces obtenues sur CONVEX −→ analyse beaucoup plus fine.
Première partie: analyse du temps
Optimization Times
teration Count
CPU Time
Line NL
Report
Exec
Min
Max
Avg (less inner loops)
---- --- ----------- -------- ----- ------ ----- ---------------129
0 SM
200
3078
3078
3078
0.916022
164
0 SM
201
3078
3078
3078
0.917755
200
0 SM
401
1977
1977
1977
0.369021
173 / 220
Deuxième partie: analyse du comportement. On peut par exemple
calculer le rapport Nb flops sur Nb ref mémoire (i.e. Vector flops /
Chime count).
Static Profile
Estimated Mflops
Vector Vector Chime (less inner loops) (plus inner loops)
Line NL Spills Flops
Count
Avg
Peak
Avg
Peak
---- --- ------ ------- ------- --------- --------- ------- -----129
0
0
28
36
18.817
19.444
18.817
19.444
164
0
0
28
36
18.875
19.444
18.875
19.444
200
0
0
6
8
12.890
18.750
12.890
18.750
174 / 220
Outline
Terminologie
Matrice-Vecteur
175 / 220
Mesurer l’efficacité d’un algorithme dans l’utilisation d’un processeur
possédant des unités pipelinées (unités de calcul ou accès mémoire).
Nombres r∞ et n 1 .
2
I
rn : performance (en Mflops) sur des vecteurs de taille n
I
r∞ : performance (en Mflops) obtenue sur de vecteurs de taille
infinie.
but : étudier la différence entre performance réelle et théorique
I
n 1 : taille minimum de vecteur pour atteindre r∞ /2
2
but : étudier les surcoûts venant des temps d’amorçage des
pipelines (de calculs ou d’accès mémoire)
176 / 220
I
Exemple du produit scalaire:
1. Sur calculateur vectoriel Cray T90, Performance de crête (1 proc)
=1800 Mflops
r∞ = 872 Mflops et n 12 = 304
2. Sur calculateur scalaire SGI Origin 2000, Performance de crête (1
proc) =360 Mflops
r∞ = 194 Mflops et n 12 = 7
c’est l’effet du cache primaire qui est ici mesuré par n 12
3. Sur machines scalaires sans cache et sans pipeline n 12 = 0 car
temps ”startup” est nul.
177 / 220
I
Approximation de la performance d’une boucle de taille n :
rn =
r∞
n1
2
n
+1
alors limn→∞ rn = r∞ et rn 1 = r∞ /2
2
I
Comment calculer r∞ et n 1 ?
2
(pour une boucle et un calculateur donnné)
1. Mesure de la performance pour différentes longueurs de vecteur.
2. Approximation aux moindres carrés
178 / 220
Traces d’exécution d’un code parallèle
I
Outils de mise au point et d’analyse de codes parallèles
Figure : Trace d’exécution VAMPIR d’un code de factorisation de matrices
creuses
I
L’instrumentation (par exemple avec l’outil VAMPIR) permet
une analyse fine sur une partie de la trace d’exécution.
creuses
I
Camemberts pour visualiser le poids relatif d’une activité
creuses
Outline
Terminologie
Matrice-Vecteur
182 / 220
Présentation des modèles utilisés pour représenter
1. l’architecture de la machine cible
2. l’algorithme
3. l’exécution
La simulation de l’exécution du modèle de programme sur le modèle
de machine cible permet d’estimer la performance réelle et de faire
une analyse de complexité de l’agorithme.
183 / 220
Modélisation de l’architecture
1. Le temps d’exécution d’une opération dépend
I
I
de la vitesse théorique du processeur et
de la localisation des données dans la hiérarchie mémoire
2. Une modélisation fine de l’architecture doit prendre en compte:
I
I
I
I
le nombre (et la taille) des registres,
la taille et la stratégie de gestion de la mémoire cache
le coût d’un accès au cache et d’un défaut de cache.
la taille et le temps d’accés à la mémoire locale.
184 / 220
1. Sur architectures parallèles à mémoire physiquement distribuée,
le temps d’accès aux données distantes est critique et il dépend:
I
I
du réseau (topologie, vitesse, nb liens/nœud)
et des stratégies de routages de messages
2. Le rapport (Vitesse processeur/Bande passante mémoire) est
une mesure de l’équilibrage globale d’une machine.
185 / 220
Calculateur
Intel iPSC/2
BBN TC2000
Intel iPSC/860
CM5
Meiko CS2
Calculateur
CONVEX C210
FUJITSU VP400
NEC-SX2
CRAY C-90
Mémoire physiquement distribuée
Vitesse/proc.
Débit lien
Nb liens
(Mflops)
(Mmots/s)
0.3
0.3
7
10.0
4.7
1
40.0
0.3
7
128.0
2.5
2
200.0
6.2
1
Mémoire partagée
Perf. crête
Débit mémoire
(Mflops) (MMots/s) MMots/Mflops
50
25
1066
1066
1300
2000
16000
24000
α
0.1
2.1
16.3
25.6
32.0
Rapport
0.5
1
1.5
1.5
Table : D’après L. Giraud (ENSEEIHT) et J. Dongarra (U. Tennessee), Mot
= 8 Octets, α=vitesse/(débit X Nb liens)
Rapport plus petit =⇒ Machine plus équilibrée (flop =⇒ 3
opérandes)
186 / 220
Modes du routage et modèles associés
Définitions/rappels
I
Les machines parallèles disposent de composants matériels
dédiés au routage (les routeurs).
I
message: entité que l’application souhaite transmettre
I
mode de commutation : façon dont sont acheminés les
messages de la source vers la destination.
I
fonction de routage : manière dont est calculée la route des
messages (indépendant du mode de commutation).
On parle de routage statique si la fonction est injective (un
seul choix possible) sinon de routage dynamique ou adaptatif.
I
congestion : d’un lien (ou nœud) est le nombre de routes
passant par ce lien (ou nœud).
187 / 220
I
paquet : l’interface réseau peut éventuellement découper le
message en paquets.
I
conséquences des paquets :
++ les ressources disponibles sur la route sont de taille bornée.
– l’interface réseau doit être capable de reconstruire le message
complet à partir de plusieurs paquets.
Hypothèses
I
le temps de propagation d’un octet entre deux nœuds est
constant.
I
deux processeurs x et y , non voisins, souhaitent échanger un
message M de taille L.
I
Soit d(x, y ) la distance entre x et y . (on ne modélisera pas la
congestion).
188 / 220
1. Commutation de messages
I
I
I
I
Chaque processeur intermédiaire sur le chemin de communication
reçoit le message M complètement avant de le réémettre en
direction du processus destinataire.
Lorsqu’un routeur reçoit un message il le stocke dans un de ses
tampons avant de le retransmettre. Il le retransmet lorsqu’un
tampon est libre sur le routeur suivant
L’entête du message permet aux routeurs intermédiaires de
calculer la route.
Modélisation :
Tcm = d(x, y )(α + Lβ),
où α est le temps d’initialisation, et β le temps de propagation
d’un octet.
189 / 220
I
Commutation de paquets par macro-pipeline : pour réduire
le coût total on divise le message en paquets de taille fixe µ :
L
Tcm = d(x, y ) + − 1 (α + µβ).
µ
s
p
2
p
Lα
opt
=
Lβ + (d(x, y ) − 1)α
µopt =
=⇒ Tcm
(d(x, y ) − 1)β
190 / 220
I
Cut-through
I
I
I
I
le message n’a pas besoin d’arriver entièrement sur un nœud pour
être renvoyé vers une autre destination.
Commutation de circuits(CC) : établissement d’une connexion
statique puis envoi des données (idem communication
télephonique). Une fois la communication établie le coût de
communication est indépendant de la distance.
Wormhole : Le message est découpé en flits (flow control
digits). Le premier flit entête établie le chemin, les flits
intermédiaires contiennent les données et le dernier flit libère les
connexions établies.
Modélisation (CC et Wormhole) : Tct = α(d(x, y )) + Lβ
191 / 220
Comparaison des modèles
I
Illustration pour x = 0, y = 3 et d(x, y ) = 3
3
2
1
0
Commutation de messages
3
2
1
0
Commutation de paquets
(macro-pipeline)
3
2
1
0
Commutation de circuits
3
2
1
0
Wormhole
Temps
En-tête
Données
192 / 220
I
Le mode par commutation de messages a été le premier utilisé
I
le mode Cut-through est maintenant classiquement utilisé sur
architectures parallèles.
I
Les modèles Cut-Through sont les plus efficaces car ils masquent
la distance entre les processeurs.
193 / 220
Conclusions pratiques
1. On se limite au modéle associé au mode Cut-Through .
2. Soit Tcom le temps de communication d’un message de L octets
entre deux processeurs.
Tcom = α + Lβ ,
et en pratique α est considéré indépendant de la distance entre
les processeurs.
3. Diffusion et diffusion personnnalisée (distribution) (message de
type OneToAll) sur un réseau de p processeurs.
3.1 sur un anneau :
Tcom = (p − 1) × (α + Lβ)
3.2 sur un réseau complet ou multi-étages :
Tcom = α + Lβ
194 / 220
Modèles de programme
I
I
Soit un programme P composé de tâches élémentaires
séquentielles Ti .
le graphe de tâches : G = (V, A)
I
I
les nœuds : Un nœud i du graphe (Ti ∈ V ) correspond à une
tâche de calcul (sans synchro).
les arcs :
un arc aij (aij ∈ A) indique une dépendance entre les tâches Ti et
Tj .
I
I
I
I
I
I
arcs orientés =⇒ graphe de précédence
arc valué =⇒ |aij | correspond généralement au coût ou volume
des communications.
notation : Ti ≺ Tj indique que Ti doit précéder Tj
le chemin critique est le chemin le plus long dans le graphe
valué
la valuation du graphe peut dépendre du modèle d’exécution
Pour un modèle d’exécution donné, le chemin critique donne une
approximation du temps d’exécution parallèle.
195 / 220
I
le graphe de flots de données : la précédence entre tâches est
induite par la circulation des données. Typiquement la tâche
correspond à l’évaluation d’une instruction et les précédences
aux accès en lecture ou en écriture.
I
Le graphe de tâches peut être dynamique et connu totalement
uniquement après exécution.
196 / 220
Modèles d’exécution
I
Définition: Le modèle d’exécution définit les règles à suivre pour
simuler l’exécution d’un programme sur une classe de machines.
I
Pour le calcul parallèle synchrone sur architectures à mémoire
partagée :
le modèle PRAM (Parallel Random Acces Memory) est
introduit.
I
Pour architectures parallèles à mémoire distribuée :
Prise en compte du placement statique/dynamique des
tâches/données sur le graphe des processeurs.
197 / 220
Modèle théorique PRAM
I
I
-Un ensemble illimité de processeurs,
-Une mémoire globale partagée infinie,
-Le programme: séquence finie d’instructions (lecture, écriture,
branchement, calcul ...)
On distingue 3 sous-modèles:
1. EREW (Exclusive Read Exclusive Write)
2. CREW (Concurent Read Exclusive Write)
3. CRCW (Concurent Read Concurent Write)
I
Exécution d’un programme sur une PRAM:
-Au premier pas toutes les opérations qui n’ont pas d’arc de
précédence entrant.
-Au second pas toutes les opérations suivantes et ainsi de suite.
198 / 220
PRAM (suite)
I
Notion de travail d’un algorithme parallèle :
Travail = Temps maximum × Pmax où
Pmax est le nombre maximum de processeurs utilisés
Nb processeurs
Travail= Pmax*T
Pmax
T
Temps
I
Idée génerale pour la recherche d’un bon algorithme:
réduire la surface du rectangle en occupant mieux les
processeurs.
199 / 220
Placement statique et/ou dynamique
I
Objectif: Trouver le “meilleur” placement du graphe des tâches
sur le graphe des processeurs
1. répartir la charge de calcul ou la charge mémoire.
2. réduire les communications et/ou synchronisations
3. minimiser le temps de calcul
I
Placement statique:
1. Hypothèses :
1.1 le graphe de tâches (temps de calcul et communication) est en
grande partie connu.
1.2 la charge du réseau et la disponibilité des processeurs est assez
stable
2. Le problème à résoudre est la plupart du temps un problème
d’optimisation combinatoire.
3. La fonction objectif est souvent le temps total (i.e. le temps de la
dernière tâche).
200 / 220
1. Exemple de fontion objectif:
1.1 soit T l’ensemble des tâches et P l’ensemble de processeurs
1.2 fonction de placement: ∀t ∈ T , ∃p ∈ P/ placer (t) = p
1.3 l’ensemble des placements réalisables (en général |P| |T |) est
|P||T |
1.4 par abus de notation on désignera, aussi par ti le temps de calcul
de la tâche
ti et par aij le temps de communication de la tâche ti à la tâche
tj .
1.5 soit t(pk ) le temps cumulé sur le processeur k alors


X
X
ti +
t(pk ) =
aij 
ti /placer (ti )=pk
tj /placer (ti )6=placer (tj )
1.6 fonction objectif Tplacer à minimiser est donc
Tplacer = max (t(pk ))
pk ∈P
201 / 220
1. on peut aussi vouloir prendre en compte un critère d’équilibrage
de charge
entre les processeurs et minimiser l’écart de temps entre les
processeurs
par rapport au temps moyen. Une fonction objectif possible est
alors:
P
X t(pl ) p
∈P
l
t(pk ) −
Tplacer =
|P|
pk ∈P
.
202 / 220
Illustration du placement statique
Figure : Parallélisation statique du produit matrice-vecteur sur réseau
hétérogène
203 / 220
Placement et régulation dynamique
1. Hypothèses
I
I
Graphe des tâches semi-prévisibles ou imprévisible (création
dynamique).
Graphe des processeurs (charge variable).
2. Composantes d’un algorithme de placement dynamique
I
I
Estimation de la charge locale et globale
Algorithme de décision
2.1 aléatoire/cyclique parmi tous les processeurs ou limité aux voisins
2.2 liste centralisée [ordonnancée] de tâches prêtes
204 / 220
Illustration du placement dynamique
Figure : Exemple de parallélisation dynamique du produit matrice-vecteur
par liste centralisée
205 / 220
I
Algorithme de décision (suite)
1. liste distribuée de tâches prêtes. Plus de travail → tirage
aléatoire d’une victime et vol de travail .
2. Gang Scheduling (regroupement logique de processus)
I
Attention au coût de la migration des données
I
I
I
Prefetch ou anticipation du chargement mémoire −→ recouvrir
communication par calcul
Redondance partielle ou totale de certaines données.
En général l’allocation statique initiale est souvent associée à
une régulation dynamique pour prendre en compte les
“imprévus” et les “imprévisibles”
206 / 220
Outline
Terminologie
Matrice-Vecteur
207 / 220
Matrice-Vecteur
On étudie la parallélisation statique, sur calculateur à mémoire
distribuée, du produit matrice-vecteur, y = A × x , où A est une
matrice carrée d’ordre N.
I
soit τ le temps pour effectuer une opération flottante
I
temps séquentiel: T1 (N) = Ts + Tpar , avec ici Ts = 0, et donc
T1 (N) = Tpar = (2N 2 − N) × τ
I
Modélisation de l’architecture
1. p : nombre de processeurs
2. réseau de type anneau et mode de routage cut-through
3. charge du processeur/réseau constante.
208 / 220
I
Modélisation de l’algorithme parallèle
:
master
x
A
x
slave 1
x
first_row(1)
first_row(2)
first_row(3)
slave 2
x
slave 3
x
I
Placement statique des données: on suppose les processus déjà créés
et la matrice déjà distribuée statiquement:
I
le processus maı̂tre (numéro 0) diffuse x à (p − 1) processus (tâches
(0,i)
tcom ) ).
I
chaque processus (incluant le maı̂tre) calcule un bout de y (tâches
i
tcal
).
I
chaque processus (sauf le maı̂tre) renvoie un bout de y maı̂tre (tâches
(i,0)
tcom )
I
le processus maı̂tre assemble la solution finale (tâche tass )
209 / 220
Le graphe des tâches (p = 4)
1
tcal
(1,0)
(0,1)
tcom
tcom
2
(0,2)
tcom
t
cal
(2,0)
tcom
3
(0,3)
tcom
tcal
(3,0)
tcom
0
tcal
t
ass
210 / 220
Modélisation de l’exécution parallèle
Tp =
Tpar
+ Tsc
p
1. On suppose un processus par processeur
2. Estimation des temps de communication (anneau, Cut-through)
diffusion de x : (p − 1) × (α + βN)
envoi du bout de y d’un esclave au maı̂tre : α + β Np
211 / 220
Diagramme d’exécution du graphe des tâches (p = 4)
P3
P2
P1
t
P0
ass
tcom
Temps
tcal
la détermination du chemin critique donne:
Tp = (p − 1) × (α + βN) +
Tp =
(2N 2 − N) × τ
N
+ (α + β )
p
p
(2N 2 − N) × τ
1
+ pα + βN(p − 1 + )
p
p
212 / 220
Analyse des résultats (I)
1. si p constant et N % alors coût dominant est
2N 2 /p
2. si N constant et p % alors Tp → (p α + β N p)
3. Speed-up : Sp (N, p) = T1 /Tp , comme
T1 = Tpar et Tsc = pα + βN(p − 1 + p1 ) on a
Sp =
Tpar
Tpar /p + Tsc
Sp =
Sp =
p
1+
pTsc
T par
p
1+
αp 2 +βN(p 2 −p+1)
(2N 2 −N)×τ
213 / 220
Analyse des résultats (II)
pour N assez grand ( 2N 1) alors
Sp =
p
1+
αp 2 +βN(p 2 −p+1)
2N 2 ×τ
et pour p assez grand ( p 2 (1 − p) )
Sp =
p
1+
p 2 (α+βN)
2N 2 ×τ
214 / 220
Analyse des résultats (III)
Soit N = 1000
1. exemple de référence : α = 4 × 10−5 , β = 2 × 10−7 , et
τ = 2 × 10−8
2. processeur 2 fois plus lent (τ = 10−8 )
3. réseau 4 fois plus rapide (α = 105 , β = 5 × 10−6 )
Etude du speed−up
15
Reference
Proc 2 fois + lent
Reseau 4 fois + rapide
Speed−up
10
5
0
0
10
20
30
40
Nombre de processeurs
50
60
70
215 / 220
I
Etude d’isoefficacité
1. Si p % alors Sp &
2. Ep = Sp /p et donc
Ep =
1
1+
p 2 (α+βN)
2N 2 ×τ
3. N constant =⇒ limp→∞ Ep (N, p) = 0
4. Par contre limn→∞ Ep (N, p) = 1
5. Comment doit on augmenter N quand p augmente de façon à
maintenir l’efficacité constante ? Ep = Ekp
1
1+
p 2 (α+βN)
2N 2 ×τ
1
=
1+
(kp)2 (α+β Ñ)
2Ñ 2 ×τ
Sous les bonnes conditions on peut montrer que Ñ doit croı̂tre
linéairement par rapport à N (Ñ = a × N + b).
216 / 220
Patrick R. Amestoy, Iain S. Duff, Jean-Yves L’Excellent, and
Xiaoye S. Li.
Impact of the implementation of MPI point-to-point
communications on the performance of two general sparse
solvers.
Parallel Computing, 29(7):833–847, 2003.
A. Beguelin, J. Dongarra, A. Geist, R. Manchek, and
V. Sunderam.
A users’ guide to PVM parallel virtual machine.
Technical Report ORNL/TM-11826, Oak Ridge National
Laboratory, Oak Ridge, Tennessee, 1991.
A. Beguelin, J. Dongarra, A. Geist, R. Manchek, and
V. Sunderam.
Recent enhancements to PVM.
Int. Journal of Supercomputer Applications, 9:108–127, 1995.
J. J. Dongarra, J. J. Du Croz, S. Hammarling, and R. J. Hanson.
An extented set of Fortran Basic Linear Algebra Subprograms.
217 / 220
ACM Transactions on Mathematical Software, 14:17 and 18–32,
1988.
Message Passing Interface Forum.
http://www-unix.mcs.anl.gov/mpi/index.html.
A. Geist, A. Beguelin, J. Dongarra, W. Jiang, R. Manchek, and
V. Sunderam.
PVM 3 User’s Guide and Reference Manual.
Technical Report ORNL/TM-12187, Engineering Physics and
Mathematics Division, Oak Ridge National Laboratory,
Tennessee, 1993.
A. Gupta, G. Karypis, and V. Kumar.
Highly scalable parallel algorithms for sparse matrix factorization.
IEEE Trans. Parallel and Distributed Systems, 8(5):502–520,
1997.
J. H. Hennessy and D. A. Patterson.
Computer Architecture: a Quantitative Approach.
218 / 220
Morgan Kaufmann Publishers, Inc, San Francisco, California,
1996.
Second Edition.
G. Karypis and V. Kumar.
MeTiS – Unstructured Graph Partitioning and Sparse Matrix
Ordering System – Version 2.0.
University of Minnesota, June 1995.
Julie Langou, Julien Langou, Piotr Luszczek, Jakub Kurzak,
Alfredo Buttari, and Jack Dongarra.
Exploiting the performance of 32 bit floating point arithmetic in
obtaining 64 bit accuracy (revisiting iterative refinement for
linear systems).
LAPACK Working Note 175, Department of Computer Science,
University of Tennessee, Knoxville, Knoxville, TN 37996, USA,
June 2006.
G. Padiou.
Systèmes opératoires, cours et notes de cours, 2ième et 3ième
année informatique et mathématiques apppliquées, 2007.
219 / 220
M. Snir, S. W. Otto, S. Huss-Lederman, D. W. Walker, and
J. Dongarra.
MPI: The Complete Reference.
The MIT Press, Cambridge, Massachusetts, 1996.
R. Clint Whaley, Antoine Petitet, and Jack J. Dongarra.
Automated empirical optimization of software and the ATLAS
project.
Parallel Computing, 27(1–2):3–35, 2001.
Also available as University of Tennessee LAPACK Working Note
#147, UT-CS-00-448, 2000
(www.netlib.org/lapack/lawns/lawn147.ps).
220 / 220

Environnement Logiciel pour le calcul scientifique

Transcription

Documents pareils

Agent Call Center Inbound 70% à 80%

Les courbes de croissance OMS pour les garçons et les filles de 0 à

X.835P2FR

ACD ADSL API Appels entrants Appels sortants

Calcul Réparti et Grid Computing - Patrick R. Amestoy

L`INFORMATIQUE en SCIENCES PHYSIQUES

Brochure PME

pontiac firebird transam 81

Mise en avant Les atouts Spécifications principales

The Egyptian Obelisks - Bibliotheca Alexandrina

Bienvenue sur la page Partenariat du portail général