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

Transcription

Calcul Réparti et Grid Computing
Patrick Amestoy et Michel Daydé (ENSEEIHT-IRIT)
préparé en collaboration avec
J.-Y. L’Excellent (INRIA/LIP-ENS Lyon)
2015-2016
1 / 396
Outline
Introduction
Introduction aux calculateurs haute-performance
Evolutions architecturales
Programmation
Conclusion
2 / 396
Outline
Introduction
Programmation
Conclusion
3 / 396
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 / 396
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 / 396
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 / 396
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 / 396
Exemples dans le domaine du calcul scientifique
I
Contraintes de durée: prévision du climat
8 / 396
Quelques exemples dans le domaine du calcul scientifique
I
Cost constraints: wind tunnels, crash simulation, . . .
9 / 396
Scale Constraints
I
large scale: climate modelling, pollution, astrophysics
I
tiny scale: combustion, quantum chemistry
10 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
Outline
Introduction
Programmation
Conclusion
19 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 [12])
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
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 / 396
Outline
Introduction
Programmation
Conclusion
42 / 396
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 / 396
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 / 396
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 / 396
Outline
Introduction
Programmation
Conclusion
46 / 396
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 / 396
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 / 396
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 / 396
Outline
Calculateurs haute-performance: concepts généraux
Introduction
Organisation des processeurs
Organisation mémoire
Organisation interne et performance des processeurs vectoriels
Organisation des processeurs RISC
Réutilisation des données (dans les registres)
Mémoire cache
Réutilisation des données (dans les caches)
Mémoire virtuelle
Réutilisation des données (en mémoire)
Interconnexion des processeurs
Les supercalculateurs du top 500 en Juin 2013
Conclusion
50 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
51 / 396
Introduction
I
Conception d’un supercalculateur
I
I
I
Déterminer quelles caractéristiques sont importantes (domaine
d’application)
Maximum de performance en respectant les contraintes de coût
(achat, maintenance,consommation)
Conception d’un processeur :
I
I
I
I
Jeu d’instructions
Organisation fonctionnelle et logique
Implantation (intégration, alimentation, . . . )
Exemples de contraintes fonctionnelles vs domaine d’application
I
I
I
Machine généraliste : performance équilibrée sur un large
ensemble de traitements
Calcul scientifique : arithmétique flottante performante
Gestion : base de données, transactionnel, . . .
52 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
53 / 396
Pipeline
I
Pipeline = principe du travail à la chaı̂ne
I
I
I
I
un traitement est découpé en un certain nombre de
sous-traitements réalisés par des unités différentes (étages du
pipeline)
les étages fonctionnent simultanément sur des opérandes
différents (éléments de vecteurs par exemple)
après amorçage du pipeline, on obtient un résultat par temps de
cyle de base
Processeur RISC :
I
I
Pipeline sur des opérations scalaires indépendantes :
a = b + c
d = e + f
Code exécutable plus complexe sur RISC :
do i = 1, n
a(i) = b(i) + c(i)
enddo
54 / 396
I
Code correspondant :
boucle :
I
i = 1
load b(i) dans registre #1
load c(i) dans registre #2
registre #3 = registre #1 + registre #2
store registre #3 dans a(i)
i = i + 1 et test fin de boucle
Exploitation du pipeline → déroulage de boucle
do i = 1,
a(i )
a(i+1)
a(i+2)
a(i+3)
enddo
n, 4
= b(i ) + c(i
)
= b(i+1) + c(i+1)
= b(i+2) + c(i+2)
= b(i+3) + c(i+3)
55 / 396
I
Sur processeur vectoriel :
do i = 1, n
a(i) = b(i) + c(i)
enddo
load vector b dans registre #1
load vector c dans registre #2
register #3 = register #1 + register #2
store registre #3 dans vecteur a
Stripmining : si n > nb (taille registres vectoriels)
do i = 1, n, nb
ib = min( nb, n-i+1 )
do ii = i, i + ib - 1
a(ii) = b(ii) + c(ii)
enddo
enddo
56 / 396
Problèmes dans la conception des pipelines
I
Beaucoup d’étages:
I
I
I
coût d’amorçage plus élévé
performances plus sensibles à la capacité de nourrir le pipeline
permet de réduire le temps de cycle
I
I
Moins d’étages
I
I
sous-instructions plus complexes
plus difficile de décroı̂tre le temps de cycle
57 / 396
Problèmes des dépendences de données
I
Exemple :
do i = 2, n
a(i) = a(i-1) + 1
enddo
a(i) initialisés à 1.
I
Exécution scalaire :
Etape 1 :
a(2) = a(1) + 1 = 1 + 1 = 2
Etape 2 :
a(3) = a(2) + 1 = 2 + 1 = 3
Etape 3 : a(4) = a(3) + 1 = 3 + 1 = 4
.....
58 / 396
I
Exécution vectorielle : pipeline à p étages → p éléments dans le
pipeline
Etages du pipe
------------------------------------------Temps
1
2
3
...
p
sortie
------------------------------------------------------t0
a(1)
t0 + dt
a(2)
a(1)
t0 + 2dt
a(3)
a(2)
a(1)
....
t0 + pdt
a(p+1)
a(p)
...
a(2)
a(1)
-------------------------------------------------------
D’où :
a(2) = a(1) + 1 = 1 + 1 = 2
a(3) = a(2) + 1 = 1 + 1 = 2
...
car on utilise la valeur initiale de a(2).
Résultat exécution vectorielle 6= exécution scalaire
59 / 396
Overlapping (recouvrement)
I
Utiliser des unités fonctionnelles en parallèle sur des opérations
indépendantes. Exemple:
do i = 1, n
A(i) = B(i) * C(i)
D(i) = E(i) + F(i)
enddo
Pipelined multiplier
B
A
C
E
D
F
Pipelined adder
I
Timeoverlapping = max{Startupmul , Startupadd + dt} + n × dt
Timeno overlap. = {Startupmul + n × dt} + {Startupadd + n × dt}
Avantages: parallélisme entre les unités fonctionnelles
indépendantes et plus de flops par cycle
60 / 396
Chaining (chaı̂nage)
I
I
La sortie d’une unité fonctionnelle est dirigée directement vers
l’entrée d’une autre unité fonctionnelle
Exemple :
do i = 1, n
A(i) = ( B(i) * C(i) ) + D(i)
enddo
B
Pipelined multiplier
Pipelined adder
A
C
D
I
Timechaining = Startupmul + Startupadd + n × dt
Timenochaining = {Startupmul + n × dt} + {Startupadd + n × dt}
Avantages : plus de flops par cyle, exploitation de la localité des
données, économie de stockage intermédiaire
61 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
62 / 396
Locality of references
Programs tend to reuse data and instructions recently used
I
Often program spends 90% of its time in only 10% of code.
I
Also applies - not as strongly - to data accesses :
I
temporal locality : recently accessed items are likely to be
accessed in the future
I
spatial locality : items whose addresses are near one another
tend to be referenced close together in time.
63 / 396
Concept of memory hierarchy - 1
In hardware : smaller is faster
Example :
I
On a high-performance computer using same technology
(pipelining, overlapping, . . . ) for memory:
I
I
signal propagation is a major cause of delay thus larger memories
→ more signal delay and more levels to decode addresses.
smaller memories are faster because designer can use more power
per memory cell.
64 / 396
Concept of memory hierarchy - 2
Make use of principle of locality of references
I
Data most recently used - or nearby data - are very likely to be
accessed again in the future
I
Try to have recently accessed data in the fastest memory
I
Because smaller is faster → use smaller memories to hold most
recently used items close to CPU and successively larger
memories farther away from CPU
→ Memory hierarchy
65 / 396
Typical memory hierarchy
Level
Registers
Cache
Main memory
Disk
Size
≤ 1KB
≤ 4MB
≤ 4GB
≥ 1GB
access
time
2-5 ns
3-10 ns
80-400 ns
5 ×106 ns
bandwidth
MB/s
400-32,000
800-5,000
400-2,000
4-32
technology
(BI)CMOS
CMOS SRAM
CMOS DRAM
magnetic disk
manag.
compiler
hardware
OS
OS/user
66 / 396
Memory interleaving
Memory Interleaving
"The memory is subdivided into several independent memory modules (banks)"
Two basic ways of distributing the addresses
Example:
10
Memory size 2 =1024 Words divided into 8 banks
Low order interleaving
High order interleaving
Real a(256)
Banks
Banks
1
2
3
4
5
6
7
8
a(1), a(2), ..., a(128)
a(129), ..., a(256)
1
2
a(1), a(9), ..., a(249)
a(2), a(10), ..., a(250)
3
4
a(3),a(11), ..., a(251)
a(4),...
5
6
7
8
a(5), ...
a(6), ...
a(7), ..., a(255)
a(8), a(16), ..., a(256)
"well adapted to pipelining memory access"
67 / 396
Effect of bank cycle time
Bank cycle time:
Time interval during which the bank
cannot be referenced again
Example
Low order interleaved memory, 4 banks, bank cycle time 3CP.
% column access
%row access
Real a(4,2)
Do j=1,2
Do i=1,4
... = a(i,j)
Enddo
Enddo
Real a(4,2)
Do i=1,4
Do j=1,2
... = a(i,j)
Enddo
Enddo
Bank
Bank
a(1,1)
1
a(1,2)
a(2,1)
2
a(3,1)
3
a(4,1)
4
1 CP
1
a(2,2)
2
a(3,2)
3
a(4,2)
10 Clock Period
a(1,1)
a(1,2)
a(2,1)
a(2,2)
a(3,1)
a(3,2)
a(4,1)
4
time
a(4,2)
18 Clock Period
Bank Conflict: Consecutive accesses to the same bank in less than bank cycle time.
Stride:
Memory address interval between successive elements
68 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
69 / 396
Organisation interne et performance des processeurs
vectoriels (d’après J. Dongarra)
I
Soit l’opération vectorielle triadique :
I
do i = 1, n
y(i) = alpha * ( x(i) + y(i) )
enddo
On a 6 opérations :
1.
2.
3.
4.
5.
Load vecteur x
Load vecteur y
Addition x + y
Multiplication alpha × ( x + y )
Store dans vecteur y
70 / 396
I
Organisations de processeur considérées :
1.
2.
3.
4.
5.
I
Séquentielle
Arithmétique chaı̂née
Load mémoire et arithmétique chaı̂nées
Load mémoire, arithmétique et store mémoire chaı̂nés
Recouvrement des loads mémoire et opérations chaı̂nées
Notations :
a:
b:
c:
d:
startup pour load mémoire
startup pour addition
startup pour multiplication
startup pour store mémoire
71 / 396
Sequential Machine Organization
a
load x
a
load y
add.
b
mult.
c
d
store
memory path busy
Chained Arithmetic
a
load x
a
load y
b
add.
c
mult.
d
store
memory path busy
72 / 396
Chained Load and Arithmetic
a
load x
load y
a
b
add.
c
mult.
d
store
memory path busy
Chained Load, Arithmetic and Store
a
load x
a
load y
b
add.
c
mult.
d
store
memory path busy
73 / 396
Overlapped Load with Chained Operations
a
load x
a
load y
b
add.
c
mult.
d
store
memory path 1 busy
memory path 2 busy
memory path 3 busy
74 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
75 / 396
The execution pipeline
Instruction
Fetch
Instruction
Decode
Execution
Memory access
and branch
completion
Write back
(write results
in register file)
Example (DLX processor, Hennessy and Patterson, 96 [10])
I
I
Pipeline increases the instruction throughput
Pipeline hazards: prevents the next instruction from executing
I
I
I
Structural hazards: arising from hardware resource conflicts
Data hazards: due to dependencies between instructions
Control hazards: branches for example
76 / 396
Instruction Level Parallelism (ILP)
I
I
Pipelining: overlap execution of independent operations →
Instruction Level Parallelism
Techniques for increasing amount of parallelism among
instructions:
I
I
I
I
reduce the impact of data and control hazards
increase the ability of processor to exploit parallelism
compiler techniques to increase ILP
Main techniques
I
I
I
I
I
I
I
I
loop unrolling
basic and dynamic pipeline scheduling
dynamic branch prediction
Issuing multiple instructions per cycle
compiler dependence analysis
software pipelining
trace scheduling / speculation
...
77 / 396
Instruction Level Parallelism (ILP)
I
I
Simple and common way to increase amount of parallelism is to
exploit parallelism among iterations of a loop : Loop Level
Parallelism
Several techniques :
I
I
Unrolling a loop statically by compiler or dynamically by the
hardware
Use of vector instructions
78 / 396
ILP: Dynamic scheduling
I
Hardware rearranges the instruction execution to reduce the
stalls.
I
Advantage: handle cases where dependences are unknown at
compile time and simplifies the compiler
I
But: significant increase in hardware complexity
I
Idea: execute instructions as soon as their data are available
Out-of-order execution
I
Handling exceptions becomes tricky
79 / 396
I
I
I
I
I
I
Scoreboarding: technique allowing instruction out-of-order
execution when resources are sufficient and when no data
dependences
full responsability for instruction issue and execution
goal : try to maintain an execution rate of one instruction /
clock by executing instructions as early as possible
requires multiple instructions to be in the EX stage
simultaneously → multiple functional units and/or pipelined
units
Scoreboard table record/update data dependences + status of
functional units
Limits:
I
I
I
amount of parallelism available between instructions
number of scoreboard entries: set of instructions examined
(window)
number and type of functional units
80 / 396
I
Other approach : Tomasulo’s approach (register renaming)
I
Suppose compiler has issued:
F10 <- F2 x F2
F2 <- F0 + F6
I
Rename F2 to F8 in the second instruction (assuming F8 is not
used)
F10 <- F2 x F2
F8 <- F0 + F6
I
Can be used in conjunction with scoreboarding
81 / 396
Impact of ILP : example
This example is from J.L. Hennessy and D.A. Patterson (1996) [10].
I
Original Fortran code
do i = 1000, 1
x(i) = x(i) + temp
enddo
I
Pseudo-assembler code
R1 <- address(x(1000))
load temp -> F2
Loop : load x(i) -> F0
F4 = F0 + F2
store F4 -> x(i)
R1 = R1 - #8 % decrement pointer
BNEZ R1, Loop % branch until end of loop
82 / 396
I
Architecture
Integer Unit
1 stage
FP add
4 stages
IF
ID
MEM
WB
FP mult
4 stages
Divide
not pipelined
Example of pipelined processor (DLX processor, Hennessy and
Patterson, 96 [10])
83 / 396
I
I
I
Latency: # cycles between instruction that produces result and
instruction that uses result
Initiation interval : # cycles between issuing 2 instructions of
same type
Latency = 0 means results can be used next cycle
Functional unit Latency Initiation interval
Integer ALU
0
1
Loads
1
1
FP add
3
1
FP mult
3
1
FP divide
24
24
Characteristics of the processor
Inst. producing result Inst. using result
FP op
FP op
FP op
store double
Load double
FP op
Load double
store double
Latency between instructions
Latency
3
2
1
0
Latency FP op to store double : forwarding hardware passes result from
ALU directly to memory input.
84 / 396
I
Straightforward code
#cycle
1
2
3
4
5
6
7
8
9
stall
F4 = F0 + F2
stall
stall
store F4 -> x(i)
R1 = R1 - #8
BNEZ R1, Loop
stall
I
9 cycles per iteration
I
Cost of calculation 9,000 cycles
I
Peak performance : 1 flop/cycle
I
Effective performance :
1
9
load lat. = 1
FP op -> store = 2
delayed branch 1
of peak
85 / 396
I
With a better scheduling
stall
F4 = F0 + F2
R1 = R1 - #8
BNEZ R1, Loop
store F4 -> x(i)
#cycle
1 load lat. = 1
2
3
4 Try keep int. unit busy
5
6 Hide delayed branching
by store
I
I
Cost of calculation 6,000 cycles
I
Effective performance :
1
6
of peak
86 / 396
I
Using loop unrolling (depth = 4)
do i = 1000, 1, -4
x(i ) = x(i )
x(i-1) = x(i-1)
x(i-2) = x(i-2)
x(i-3) = x(i-3)
enddo
+
+
+
+
temp
temp
temp
temp
87 / 396
I
Pseudo-assembler code (loop unrolling, depth=4):
#cycle
1
F4 = F0 + F2
3
store F4 -> x(i)
6
load x(i-1) -> F6
7
F8 = F6 + F2
9
store F8 -> x(i-1) 12
load x(i-2) -> F10 13
F12= F10+ F2
15
store F12-> x(i-2) 18
load x(i-3) -> F14 19
F16= F14+ F2
21
store F16-> x(i-3) 24
R1 = R1 - #32
25
BNEZ R1, Loop
26
stall
27
I
I
I
1 stall
2 stalls
1 stall
2 stalls
1 stall
2 stalls
1 stall
2 stalls
Cost of calculation 1000
4 × 27 = 6750 cycles
Effective performance : 1000
6750 = 15% of peak
88 / 396
I
I
I
I
Using loop unrolling (depth = 4) and scheduling
#cycle
1
load x(i-1) -> F6
2
load x(i-2) -> F10 3
load x(i-3) -> F14 4
F4 = F0 + F2
5
F8 = F6 + F2
6
F12= F10+ F2
7
F16= F14+ F2
8
store F4 -> x(i)
9
store F8 -> x(i-1) 10
store F12-> x(i-2) 11
R1 = R1 - #32
12
BNEZ R1, Loop
13
store F16-> x(i-3) 14
4 × 14 = 3500 cycles
3500 = 29% of peak
89 / 396
I
I
Now assume superscalar pipeline : integer and floating point
operations can be issued simultaneously
Using loop unrolling with depth = 5
Integer inst. | Float.inst.|#cycle
___________________________________________
Loop: load x(i) -> F0 |
|
1
load x(i-1)-> F6 |
|
2
load x(i-2)-> F10| F4 =F0 +F2 |
3
load x(i-3)-> F14| F8 =F6 +F2 |
4
load x(i-4)-> F18| F12=F10+F2 |
5
store F4 ->x(i) | F16=F14+F2 |
6
store F8 ->x(i-1)| F20=F18+F2 |
7
store F12->x(i-2)|
|
8
store F16->x(i-3)|
|
9
R1 = R1 - #40
|
| 10
BNEZ R1, Loop
|
| 11
store F20->x(i-4)|
| 12
I
I
I
I
5 × 12 = 2400 cycles
2400 = 42% of peak
Performance limited by balance between int. and float. instr.
90 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
91 / 396
I
Améliorer l’accès aux données et exploiter la localité spatiale et
temporelle des références mémoire
I
Déroulage de boucles : réduit le nombre d’accès mémoire en
utilisant le plus de registres possible
I
Utiliser des scalaires temporaires
I
Distribution de boucles : si nombre de données réutilisables >
nombre de registres : substituer plusieurs boucles à une seule
92 / 396
Déroulage de boucle
Objectif : réduire nombre d’accès mémoire et améliorer pipeline
opérations flottantes.
I
Produit matrice-vecteur : y ← y + At × x
do ...
do ...
y(i) = y(i) + x(j)*A(j,i)
enddo
enddo
I
2 variantes :
I
AXPY :
do j = 1, N
do i = 1, N
...
I
DOT
do i = 1, N
do j = 1, N
...
93 / 396
DOT variant
Processeurs RISC mieux adaptés à DOT que AXPY
do i = 1, N
temp = 0.
do j = 1, N
temp = temp + x(j)*A(j,i)
enddo
y(i) = y(i) + temp
enddo
Stride = 1 dans boucle la plus interne
load A(j,i)
load x(j)
perform x(j)*A(j,i) + temp
Ratio Flops/références mémoire =
2
2
=1
94 / 396
Réutilisation de x(j) : déroulage à une profondeur 2
* Cleanup odd iteration
i = MOD(N,2)
if ( i >= 1 ) then
do j = 1, N
y(i) = y(i) + x(j)*A(j,i)
enddo
end if
* Main loop
imin = i + 1
do i = imin, N, 2
temp1 = 0.
temp2 = 0.
do j = 1, N
temp1 = temp1 + A( j,i-1) * x(j)
temp2 = temp2 + A( j,i ) * x(j)
enddo
y(i-1) = y(i-1) + temp1
y(i ) = y(i ) + temp2
enddo
95 / 396
load A(j,i-1)
load x(j)
perform A(j, i-1 ) * x(j) + temp1
load A(j,i)
perform A(j,i
) * x(j) + temp2
I
I
Déroulage à une profondeur de 4 :
I
Déroulage à une profondeur k:
4
3
8
5
2k
k+1
96 / 396
Performance of y = At x on HP 715/64
45
Rolled
40
Unrolled 2
Unrolled 4
35
Unrolled 8
MFlops
30
25
20
15
10
5
0
200
400
600
Size
800
1000
1200
Figure : Effect of loop unrolling on HP 715/64
97 / 396
Performance of y = At x on CRAY T3D
50
45
Rolled
Unrolled 2
40
Unrolled 4
Unrolled 8
MFlops
35
30
25
20
15
10
5
0
200
400
600
Size
800
1000
1200
Figure : Effect of loop unrolling on CRAY T3D
98 / 396
AXPY variant
Habituellement préférée sur processeurs vectoriels
do j = 1, N
do i = 1, N
y(i) = y(i) + x(j)*A(j,i)
enddo
enddo
Stride > 1 dans la boucle la plus interne
load A(j,i)
load y(i)
perform x(j)*A(j,i) + y(i)
store result in y(i)
2
3
99 / 396
Réutilisation de y(i) : déroulage à profondeur 2
* Cleanup odd iteration
j = MOD(N,2)
if ( j .GE. 1 ) then
do i = 1, N
y(i) = y(i) + x(j)*A(j,i)
enddo
end if
* Main loop
jmin = j + 1
do j = jmin, N, 2
do i = 1, N
y(i) = y(i)+A(j-1,i)*x(j-1)+A(j,i)*x(j)
enddo
enddo
load y(i)
load A(j-1,i)
perform A(j-1,i ) * x(j-1) + y(i)
load A(j,i)
perform A(j,i) * x(j) + y(i)
store result in y(i)
I
Ratio Flops/références mémoire = 1
I
Déroulage à profondeur 4 → Ratio =
I
Déroulage à profondeur p → Ratio =
4
3
2p
2+p
101 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
102 / 396
Organisation d’une mémoire cache
I
Cache
I
I
I
Ligne de cache
I
I
I
I
I
Unité de transfert entre cache et mémoire principale
Défaut de cache
I
I
Buffer rapide entre les registres et la mémoire principale
Divisé en lignes de cache
Référence à une donnée non présente dans le cache
Stratégie de choix d’une ligne à remplacer (LRU parmi les
éligibles)
Une ligne de cache contenant la donnée est chargée de la
mémoire principale dans le cache
Problème de la cohérence de cache sur les multiprocesseurs à
mémoire partagée
Rangement des données dans les caches
I
correspondance mémoire ↔ emplacements dans le cache
103 / 396
I
Stratégies les plus courantes :
I
I
I
I
Conception des caches :
I
I
I
I
“direct mapping”
“fully associative”
“set associative”
L octets par ligne de cache
K lignes par ensemble (K est le degré d’associativité)
N ensembles
Correspondance simple entre l’adresse en mémoire et un
ensemble :
I
I
N = 1 : cache “fully associative”
K = 1 : cache “direct mapped”
104 / 396
I
“Direct mapping”
I
I
I
Chaque bloc en mémoire ↔ un placement unique dans le cache
Recherche de données dans cache peu coûteuse (mais
remplacement coûteux)
Problème de contention entre les blocs
line
cache
main memory
I
“Fully associative”
I
I
Pas de correspondance a priori
Recherche de données dans cache coûteuse
105 / 396
I
“Set associative”
I
I
I
Cache divisé en plusieurs ensembles
Chaque bloc en mémoire peut être dans l’une des lignes de
l’ensemble
“4-way set associative” : 4 lignes par ensemble
cache set #k
line 1
line 2
line 3
line 4
line
main memory
106 / 396
Gestion des caches
I
I
Coût d’un défaut de cache : entre 2 et 50 C (temps de cycle)
“Copyback”
I
Pas de m-à-j lorsqu’une ligne de cache est modifiée, excepté lors
d’un cache flush ou d’un défaut de cache
Mémoire pas toujours à jour.
Pas de problème de cohérence si les processeurs modifient des
lignes de cache indépendantes
I
“Writethrough”
I
Donnée écrite en mémoire chaque fois qu’elle est modifiée
Données toujours à jour.
Pas de problème de cohérence si les processeurs modifient des
données indépendantes
107 / 396
Cache coherency problem
Processor # 1
Processor # 2
cache
cache
cache line
X
I
Y
Cache coherency mechanisms to:
I
I
I
avoid processors accessing old copies of data (copyback and
writethrough)
update memory by forcing copyback
invalidate old cache lines
108 / 396
Cache coherency problem
Processor # 1
Processor # 2
cache
cache
cache line
X
I
Cache coherency mechanisms to:
I
I
I
I
Y
avoid processors accessing old copies of data (copyback and
writethrough)
update memory by forcing copyback
invalidate old cache lines
Example of mechanism (snooping):
I
I
I
assume writethrough policy
Each processor observes the memory accesses from others
If a write operation occurs that corresponds to a local cacheline,
invalidate local cacheline
109 / 396
Processor
DEC 21164
IBM Power2
MIPS R8000
∗
Line size
Level
Size
Organization
32 B
1
2∗
3∗
1
8 KB
96 KB
1-64 MB
128 KB /
256 KB
16 KB
4-16 MB
Direct-mapped
3-way ass.
Direct-mapped
4-way-ass.
128 B /
256 B
16 B
1
2∗
miss
C
C
C
C
Access /
cycle
2
2
2
2
7C
50 C
2
2
2
≥8
≥ 12
8
Direct-mapped
4-way-ass.
Cache configurations on some computers.
: data + instruction cache
I
Current trends:
I
I
Large caches of several MBytes
Several levels of cache
110 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
111 / 396
Example
I
I
cache 10 times faster than memory, hits 90% of the time.
What is the gain from using the cache ?
I
I
I
Cost cache miss: tmiss
Cost cache hit: thit = 0.1 × tmiss
Average cost:
112 / 396
Example
I
I
cache 10 times faster than memory, hits 90% of the time.
What is the gain from using the cache ?
I
I
I
I
Cost cache miss: tmiss
Cost cache hit: thit = 0.1 × tmiss
Average cost: 90%(0.1 × tmiss ) + 10% × tmiss
tmiss ×100%
1
gain = 90%×(0.1×t
= (0.9×0.1)+0.1
=
miss )+10%×tmiss
1
0.19
= 5.3
(similar to Amdahl’s law)
113 / 396
Il est critique d’utiliser au maximum les données dans le cache ↔
améliorer le % de succès de cache
I
Exemple : effet du % de défauts de cache sur un code donné
I
I
I
Pmax performance lorsque toutes les données tiennent dans le
cache (hit ratio = 100%). Tmin temps correspondant.
Lecture de donnée dans le cache par une instruction et exécution
: thit = 1 cycle
Temps d’accès à une donnée lors d’un défaut de cache : tmiss =
10 ou 20 cycles (exécution instruction tmiss + thit )
I
Ttotal = %hits.thit + %misses × (tmiss + thit )
I
Topt = 100% × thit
I
Perf =
Topt
Ttotal
114 / 396
Tmiss
10
20
10
20
%hits
100%
99%
99%
95%
95%
Tps hits
1.00
0.99
0.99
0.95
0.95
Tps misses
0.00
0.11
0.21
0.55
1.05
Ttotal
1.00
1.10
1.20
1.50
2.00
Perf.
100%
91%
83%
66%
50%
Table : Effet des défauts de cache sur la performance d’un code (exprimés
en pourcentages vs pas de défaut de cache).
115 / 396
Efficient cache utilization: Exercise
Reuse as much as possible data held in cache ↔ Improve cache hit
ratio
I
I
I
I
Cache : single block of CS (cache size) words
When cache is full: LRU line returned to memory
Copy-back: memory updated only when a modified block
removed from cache
For simplicity, we assume cache line size L=1
Example from D. Gannon and F. Bodin :
do i=1,n
do j=1,n
a(j) = a(j) + b(i)
enddo
enddo
1. Compute the cache hit ratio (assume n much larger than CS).
2. Propose a modification to improve the cache hit ratio.
116 / 396
I
I
I
I
Total number of memory references = 3 × n2 i.e. n2 loads for a,
n2 stores for a, and n2 loads for b (assuming the compiler is
stupid).
Total number of flops = n2
Cache empty at beginning of calculations.
Inner loop:
do j=1,n
a(j) = a(j) + b(i)
enddo
Each iteration reads a(j) and b(i), and writes a(j)
For i=1 → access to a(1:n)
For i=2 → access to a(1:n)
As n >> CS, a(j) no longer in cache when accessed again,
therefore:
I
I
I
I
each read of a(j) → 1 miss
each write of a(j) → 1 hit
each read of b(i) → 1 hit (except the first one)
Hit ratio =
# of hits
=
Mem.Refs
2
3
= 66%
117 / 396
blocked version
The inner loop is blocked into blocks of size nb < CS so that nb
elements of a can be kept in cache and entirely updated with b(1:n).
do j=1,n,nb
jb = min(nb,n-j+1)
! nb may not divide n
do i=1,n
do jj=j,j+jb-1
a(jj) = a(jj) + b(i)
enddo
enddo
enddo
118 / 396
To clarify we load the cache explicitely; it is managed as a 1D array :
CA(0:nb)
do j=1,n,nb
jb = min(nb,n-j+1)
CA(1:jb) = a(j:j+jb-1)
do i=1,n
CA(0) = b(i)
do jj=j,j+jb-1
CA(jj-j+1) = CA(jj-j+1) + CA(0)
enddo
enddo
a(j:j+jb-1) = CA(1:jb)
enddo
Each load into cache is a miss, each store to cache is a hit.
119 / 396
I
I
Total memory references = 3n2
Total misses:
I
I
I
I
n
× nb
load a = nb
n
load b = nb
×n
n2
Total = n + nb
Total hits = 3n2 − n −
n2
nb
hits
Hit ratio =
≈1−
Mem.Refs
if nb is large enough.
= (3 −
1
3nb
1
nb )
× n2 − n
≈ 100%
120 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
121 / 396
Mémoire virtuelle
I
Mémoire réelle : code et données doivent être logés en mémoire
centrale
I
Mémoire virtuelle : mécanisme de pagination entre la mémoire
et les disques
Une pagination mémoire excessive peut avoir des conséquences
dramatiques sur la performance !!!!
I
TLB :
I
I
I
I
Translation Lookaside Buffer : correspondance entre l’adresse
virtuelle et l’adresse réelle d’une page en mémoire
TLB sur IBM Power4/5: 1024 entrées
Défaut de TLB : 36 C environ
AIX offre la possibilité d’augmenter la taille des pages (jusqu’à 16
MB) pour limiter les défauts de TLB.
122 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
123 / 396
Exercice sur la réutilisation des données (en mémoire)
(inspiré de (Dongarra, Duff, Sorensen, van der Vorst [6]))
C ←C +A×B
A, B, C : matrices n × n, n = 20000, stockées par colonnes
I
Calculateur vectoriel (Performance de crête 50 GFlop/s)
I
Mémoire virtuelle (remplacement page : LRU)
I
1 page mémoire = 2Mmots = 100 colonnes de A, B, ou C
(1 mot = 8 bytes)
I
1 défaut de page ≈ 10−4 secondes
I
Stockage de A, B, et C : 3 × 400Mmots = 3 × 3.2 GB = 9.6 GB
I
capacité mémoire : 128 pages soit:
128 × 2Mmots = 256Mmots = 2GB → A, B, C ne peuvent être
stockées totalement
124 / 396
Variante (1) : ijk
do i = 1, n
do j = 1, n
do k = 1, n
Cij <- Cij + Aik * Bkj
enddo
enddo
enddo
1. Quel est le nombre de défauts de pages et le temps de calcul de
cette variante (ijk) ?
la variante (jki) ?
la variante (jki) avec blocage sur j et k par blocs de taille 4
pages mémoire ?
125 / 396
Variante (1) : ijk
do i = 1, n
do j = 1, n
do k = 1, n
enddo
enddo
enddo
Si accès en séquence aux colonnes d’une matrice, 1 défaut de page
toutes les 100 colonnes.
n
= 200 défauts de page.
Accès à une ligne de A → 100
2
10
D’où 200 × 20000 = 8 × 10 defauts de page.
8 × 1010 défauts de page × 10−4 sec. = 8 Msec ≈ 128 jours de calcul
126 / 396
Variante (2) : jki
do j = 1, n
do k = 1, n
do i = 1, n
enddo
enddo
enddo
Pour chaque j :
I
toutes colonnes de A accédées : n*200 défauts de page
I
accés aux colonnes de B et C : 200 défauts de page
I
total ≈ 4 × 106 défauts de page
Temps d’exécution ≈ 4 × 106 × 10−4 sec = 400 sec
127 / 396
Variante (3) : jki bloqué
Les matrices sont partitionées en blocs de colonnes tq bloc-colonne
(nb = 400 colonnes) = 4 pages mémoire.
Réutilisation maximale des sous-matrices en mémoire.
* Organisation des calculs sur des sous-matrices
do j = 1, n, nb
jb = min(n-j+1,nb)
do k = 1, n, nb
sectioning loops
kb = min(n-k+1,nb)
* Multiplication sur les sous-matrices
* C1:n,j:j+jb-1 <- C1:n,j:j+jb-1
*
+ A1:n,k:k+kb-1 * Bk:k+kb-1,j:j+jb-1
do jj = j, j+jb-1
do kk = k, k+kb-1
do i = 1, n
Cijj <- Cijj + Aikk * Bkkjj
enddo enddo enddo
enddo
enddo
Défauts de page :
I
nb = 400 colonnes (4 pages mémoire)
I
accès à B et C, défauts de page lors de la boucle en j: 200
défauts de page
I
n/nb accès (boucle en j) à A par blocs de colonnes, pour chaque
indice k: 200, soit n/nb × 200 au total.
I
n
+ 2) × 200 défauts de page
Total ≈ ( nb
I
nb = 400 donc
I
et donc ≈ 104 défauts de page
I
n
nb
= 50
Temps de chargement mémoire = 1 sec
Attention : le temps de calcul n’est plus négligeable !!
Temps = 2 × n3 /vitesse ≈ 320 secondes
Idées identiques au blocage pour cache
Blocage : très efficace pour exploiter au mieux une hiérarchie
mémoire (cache, mémoire virtuelle, . . . )
129 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
130 / 396
I
Réseaux constitués d’un certain nombre de boı̂tes de connexion
et de liens
I
I
I
I
Commutation de circuits : chemin créé physiquement pour toute
la durée d’un transfert (idéal pour un gros transfert)
Commutation de paquets : des paquets formés de données +
contrôle trouvent eux-même leur chemin
Commutation intégrée : autorise les deux commutations
précédentes
Deux familles de réseaux distincts par leur conception et leur
usage :
I
I
Réseaux mono-étage
Réseaux multi-étages
131 / 396
Réseau Crossbar
0
1
2
o
o
o
o
o
o
o
o
o
o
3
o
o
o
o
o
1
o
o
2
3
Toute entrée peut être connectée à toute sortie sans blocage.
Théoriquement, le plus rapide des réseaux mais concevable seulement
pour un faible nombre d’Entrées/Sortie.
132 / 396
Réseaux multi-étages
Constitués de plus d’un étage de boitiers de connexion. Système de
communication permettant le plus grand nombre possible de
permutations entre un nombre fixe d’entrées et de sorties.
A chaque entrée (ou sortie) est associée une unité fonctionnelle.
Nombre d’entrées = nombre de sorties = 2p .
0
1
2
0
1
2
3
3
4
5
6
7
4
5
6
7
Figure : Exemple de réseau multi-étage avec p=3.
Réseaux birectionnels ou doublement du réseau.
133 / 396
Boı̂te de connexion élémentaire
Elément de base dans la construction d’un réseau : connexion entre
deux entrées et deux sorties
I Boı̂te à deux fonctions (B2F) permettant les connexions directe
et croisée contrôlée par un bit
I
Boı̂te à quatre fonctions (B4F) permettant les connexions
directe, croisée,à distribution basse et haute contrôlée par deux
bits.
134 / 396
I
Topologie : mode d’assemblage des boı̂tes de connexion pour
former un réseau de N = 2p entrées / N sorties. La plupart des
réseaux sont composés de p étages de N2 boı̂tes.
I
Exemple : Réseau Omega
Topologie basée sur le “Perfect Shuffle” (décalage à gauche des
bits plus boucle) permutation sur des vecteurs de 2p éléments.
0
0
1
1
2
2
3
3
4
5
4
5
6
6
7
7
Le réseau Omega reproduit à chaque étage un “Perfect Shuffle”.
Autorise la distribution d’une entrée sur toutes les sorties
(“broadcast”).
135 / 396
0
0
0
0
A
1
1
2
2
3
B
3
1
E
I
F
J
G
K
2
2
3
1
3
4
4
5
4
4
C
5
5
5
6
6
7
6
D
6
H
7
7
L
7
Réseau Omega 8 × 8.
136 / 396
I
Anneau
Proc 0
I
Proc 1
Proc 2
Proc n
Grille
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Utilisé sur Intel DELTA et PARAGON, . . .
137 / 396
I
0
I
0
I
Shuffle Exchange : Perfect Shuffle avec en plus Proc # i
connecté à Proc # (i+1)
1
2
3
4
5
6
7
N-cube ou hypercube : Proc #i connecté au Proc # j si i et j
diffèrent d’un seul bit.
1
2
3
4
5
6
7
Grand classique utilisé sur hypercubes Intel (iPSC/1, iPSC/2,
iPSC/860), machines NCUBE, CM2, SGI . . .
138 / 396
Figure : 4-Cube in space.
139 / 396
Topologies usuelles pour les architectures distribuées
I
Notations :
I
I
I
I
I
I
# procs = N = 2p
diamètre = d (chemin critique entre 2 procs)
# liens = w
Anneau : d = N2 , w = N
1
1
1
Grille 2D : d = 2 × (N 2 − 1), w = 2 × N 2 × (N 2 − 1)
Tore 2D (grille avec rebouclage sur les bords) :
1
d = N2,w = 2 × N
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
Proc
I
Hypercube ou p-Cube : d = p, w =
N×p
2
140 / 396
Remarques
I
Tendance actuelle:
I
I
I
Réseaux hiérarchiques/multi-étages
Beaucoup de redondances (bande passante, connections
simultanées)
Conséquence sur les calculateurs haute performance:
I
I
Peu de différence de coût selon sources/destinations
La conception des algorithmes parallèles ne prend plus en compte
la topologie des réseaux (anneaux, . . . )
141 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
142 / 396
Statistiques Top 500 (voir www.top500.org)
I
Liste des 500 machines les plus puissantes au monde
I
Mesure: GFlops/s pour pour la résolution de
Ax = b, A matrice dense.
I
Mises à jour 2 fois par an (Juin/ISC, Novembre/SC).
I
Sur les 10 dernières années la performance a augmenté plus vite
que la loi de Moore:
143 / 396
Analyse des sites - Definitions
I
Rang (noté # par la suite): Position dans le top 500.
I
Rpeak (Gflop/s): Performance crête de la machine en nombre
d’opérations flottantes par secondes.
I
Rmax (Gflop/s): Performance maximum obtenue sur le test
LINPACK
I
Nmax: Taille du problème ayant servi à obtenir Rmax.
Power (MWatt/s) : Watt/s consommés (voir aussi
www.green500.org)
I
I
I
I
I
L’efficacité énergétique s’améliore
Les calculateurs à efficacité energétique la plus forte possédent
des processeurs cell
Green500.org: #1: 3208 Mflops/Watt, CINECA (Bologne)
Top500 performance #1: 1900 Mflops/Watt, Tianhe-2 (Chine)
(#1 en 2010 : 253 Mflops/Watt !!!)
144 / 396
Top 500: évolution des performances (RMAX)
I
June 1997: ASCI Red,
Sandia NL
I
I
I
I
#1 = 280 TFlop/s
#500 = 4 TFlop/s
June 2008: Roadrunner,
LosAlamos NL
I
#1 = 1.1 TFlop/s
(effectif)
#500 = 7.7 GFlop/s
June 2007:IBM Blue
gene, Livermore NL
I
I
I
I
#1 = 1 PFlop/s (1026
TFlop/s)
#500 = 4 TFlop/s
June 2010: Jaguar,
OakRidge NL
I
I
#1 = 1,75 PFlop/s (1026
TFlop/s)
#500 = 25 TFlop/s
June 2013: #1 Tianhe-2 (MilkyWay-2) National Univ. of Def.
Tech., Chine, 33.8 Pflops (> 3 Millions coeurs)
#500 = 100 Tera
145 / 396
Evolution des performances energétiques des Top #1
I
Entre 2002 et 2005 :
NEC earth simulator (40 Tflop/s) : 6 MFlops/Watt
I
Entre 2005 et 2007 :
IBM Bleu gene L (280 Tflop/s) : 205 Mflops/Watt
I
2008 :
Roadrunner Blade center ( 1 Pflop/s) : 444 Mflops/Watt
I
2010 :
Jaguar, Cray XT5 Opteron 6 core (1.7 Pflop/s) :
253 Mflops/Watt
I
2013 :
Tianhe-2, Cray XT5 Opteron 6 core (33.8 Pflop/s) :
1900 Mflops/Watt
146 / 396
Evolution des performances (RMAX)
147 / 396
Top 5 (Juin 2013)
148 / 396
Distribution géographique
149 / 396
Répartition par segment d’activité
150 / 396
Statistiques constructeurs
151 / 396
Analyse des familles de processeurs
152 / 396
Analyse des familles de processeurs
153 / 396
Analyse des sites français – Juin 2013 (23 dans Top 500)
Rang
11
15
25
37
38
54
123
Site
Total
CEA/TGCC
CEA
CNRS/IDRIS
EDF R&D
Météo France
Airbus
Système
SGI ICE X, Xeon, 8C, 2.6GH
Bullx, Xeon, 8C 2.7GH
Bullx, super-node
BlueGene/Q, Power BQC, 1.6GH
BlueGene/Q, Power BQC, 1.6GH
Bullx
HP POD - Cluster Platform
Cores
(x1000)
110K
77K
136K
65K
65K
26K
25,8
Rmax
(Tflops)
2098
1359
1050
716
716
500
243
Power
(Mw)
2,1
2,2
4,5
0.33
0.33
401
Autres domaines concernés (Institution financieres (4), Service,
Automobile, Simulation (EADS, CNES))
Meteo France, Espace Clément Ader (Toulouse), 1 Petaflops en 2014
et 5 Petaflops en 2016
154 / 396
Outline
Introduction
Mémoire cache
Mémoire virtuelle
Conclusion
155 / 396
Conclusion
I
Performance :
I
I
Horloge rapide
Parallélisme interne au processeur
I
I
I
I
Traitement pipeliné
Recouvrement, chaı̂nage des unités fonctionnelles
Parallélisme entre processeurs
Mais :
I
Accès aux données :
I
I
I
I
Communications entre processeurs
Complexité du hardware
Techniques de compilation : pipeline / vectorisation /
parallélisation
Comment exploiter efficacement l’architecture ?
156 / 396
Ecriture de code efficace (I) : MFLOPS ou MIPS ?
I
MFLOPS: floating point operations /sec.
Ne dépend pas du calculateur
I
MIPS: instructions de bas-niveau
Dépend du calculateur
I
Watt: code efficace sur des machines a faible consommation en
Watt par proc. (Exemple des proc. Cell).
I
Précision des calculs: travail partiel en précision numérique
affaiblie (plus efficace).
157 / 396
Ecriture de code efficace (II)
I
Facteurs architecturaux influençant la performance :
I
I
I
I
I
débit et latence mémoire
coûts des communications et de synchronisation
temps d’amorçage des unités vectorielles
besoins en entrées/sorties
Facteurs dépendant de l’application :
I
parallélisme (dépend des algorithmes retenus)
I
I
I
I
I
régularité des traitements
équilibrage des traitements
volume de communications (localité)
granularité - scalabilité
Localité des données (spatiale et temporelle)
encore plus critique sur les architectures Cell et GPU (Graphical
Proc Unit)
158 / 396
Notion de calcul potentiellement efficace
I
Proposition: Soient x et y des vecteurs et A, B, C des matrices
d’ordre n; le noyau de calcul (1) x = x + αy est potentiellement
moins efficace que le noyau (2) y = A × x + y qui est
potentiellement moins efficace que le noyau (3) C = C + A × B
I
Exercice : justifier la proposition précédente.
159 / 396
I
I
La mesure du rapport entre le nombre d’opérations flottantes et
de réferences mémoire pour chacun des noyaux de calcul
explique le potentiel.
x = x + αy
I
I
I
I
y =A×x +y
I
I
I
I
n2 références mémoire
2n2 opérations flottantes
rapport Flops/Ref = 2
C =C +A×B
I
I
I
I
3n références mémoire
2n opérations flottantes
rapport Flops/Ref = 2/3
4n2 références mémoire
2n3 opérations flottantes
rapport Flops/Ref = n/2
Typiquement Vitesse (3) = 5 × vitesse(2) et vitesse(2) = 3 ×
vitesse(1) . . . si on utilise des bibliothèques optimisées !
160 / 396
Limites de l’optimisation de code et de la
vectorisation/parallélisation automatiques
C ← α × A × B + βC (DGEMM du BLAS)
20
30
40
DO 40 j = 1, N
................
DO 30 l = 1, K
IF ( B( l, j ) .NE. ZERO ) THEN
TEMP = ALPHA * B( l, j )
DO 20 i = 1, M
C( i, j ) = C( i, j ) + TEMP * A( i, l )
CONTINUE
END IF
CONTINUE
CONTINUE
Plupart des compilateurs : parallélisent la boucle d’indice j et
optimisent / vectorisent la boucle d’indice i
161 / 396
Table : Performance de versions différentes de GEMM sur processeurs RISC
avec des matrices 128 × 128.
Calculateur
DEC 3000/300 AXP
HP 715/64
IBM RS6000/750
Pentium 4
standard
23.1
16.9
25.2
113
optimisé
48.4
38.4
96.1
975
perf. de crête
150.0
128.0
125.0
3600
I
Plupart des optimisations réalisées par les compilateurs sur la
boucle interne
I
En théorie très bon potentiel grâce au rapport entre opérations
flottantes et références mémoire : ( 4n2 références mémoire, 2n3
opérations flottantes)
i.e.
n
2
mais les compilateurs ne savent pas l’exploiter !!
162 / 396
I
Optimisation de code :
I
I
I
I
I
I
I
Améliorer l’accès aux données et exploiter la localité spatiale et
temporelle des références mémoire
Déroulage de boucles : réduit le nombre d’accés mémoire en
améliorant la réutilisation des registres, permet aussi une
meilleure exploitation du parallélisme interne aux processeurs
Blocage pour une utilisation efficace du cache : améliore la
localité spatiale et temporelle
Copie des données dans des tableaux de travail pour forcer la
localité et éviter des ”strides” critiques (pas toujours possibles car
parfois trop coûteux)
”prefetch” des données
Utilisation de l’assembleur (cas désespéré !!)
Utilisation de bibliothèques optimisées (cas ideal !!)
163 / 396
Utilisation d’une bibliothèque optimisée
I
Noyaux de calcul matriceXmatrice optimisés existent :
I
I
ATLAS - Automatic Tuned Linear Algebra Software.
http://netlib.enseeiht.fr/atlas/
Goto from Univ. Texas at Austin
http://www.cs.utexas.edu/users/flame/goto/
Figure : Comparaison de la performance de noyaux de calcul en algèbre
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
165 / 396
Outline
166 / 396
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.
167 / 396
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)
168 / 396
Outline
169 / 396
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.
170 / 396
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)
171 / 396
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)
172 / 396
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
173 / 396
Outline
174 / 396
Un arbre qui cache la forêt
175 / 396
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
...
176 / 396
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
177 / 396
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 ?
178 / 396
Outline
179 / 396
(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 !!
180 / 396
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) )
181 / 396
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 )
182 / 396
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)
183 / 396
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)
184 / 396
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.
185 / 396
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.
186 / 396
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
187 / 396
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
188 / 396
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 !!
189 / 396
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.
190 / 396
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
191 / 396
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
192 / 396
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%
193 / 396
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.
194 / 396
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
195 / 396
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)
196 / 396
Outline
Description des standards pour la programmation en mode message
Distributed and heterogeneous computing using PVM
197 / 396
Description des standards pour la programmation en mode
message
198 / 396
Outline
199 / 396
I
Short overview of the PVM computing environment.
I
Simple example.
I
XPVM tracing tool used for illustration
I
Complete description of PVM : [2, 8, 3].
I
Many of the examples we use are coming from these references.
200 / 396
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.
201 / 396
Workstation
Workstation
Fast network
Workstation
Workstation
Slow Network
Workstation
Mini−Comp
Super−Comp
Figure : Example of virtual machine
202 / 396
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).
203 / 396
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.
204 / 396
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.
205 / 396
We focus on the main procedures of the PVM user library.
Complete version of PVM3 user library [8] available on netlib.
206 / 396
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.
208 / 396
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.
209 / 396
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
......
210 / 396
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).
211 / 396
Memory/data
Send buffer
pvmfpack
pvmfsend
Sending Process
Memory/data
Receive buffer
pvmfunpack
pvmfrecv
Receiving Process
Figure : Illustration of send/receive main steps
212 / 396
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.
213 / 396
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.
214 / 396
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.
215 / 396
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.
216 / 396
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)
217 / 396
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.
218 / 396
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.
219 / 396
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
221 / 396
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
222 / 396
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.
223 / 396
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 )
224 / 396
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.
225 / 396
• 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 [5]) which performs:
y = α A x + βy
226 / 396
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
227 / 396
*
*
*
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
228 / 396
* 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
229 / 396
*
*
*
*
*
*
*
*
*
-----------------------------------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
230 / 396
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
231 / 396
*
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
232 / 396
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
233 / 396
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.
234 / 396
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
235 / 396
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.
236 / 396
Figure : XPVM trace of the static parallelisation of the matrix-vector
product
Note that the fastest computer (sharon) is idle most of the time.
237 / 396
Outline
238 / 396
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 [14, 7]
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).
239 / 396
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
240 / 396
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
241 / 396
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.
242 / 396
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
243 / 396
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
244 / 396
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́.
245 / 396
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).
246 / 396
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.
247 / 396
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.
248 / 396
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).
249 / 396
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.
250 / 396
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, . . . )
251 / 396
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).
252 / 396
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
253 / 396
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.
254 / 396
I
suivantes:
1. MPI IRsend ( . . . , Ireq, . . . )
2. MPI ISsend ( . . . , Ireq, . . . )
3. MPI IBsend ( . . . , Ireq, . . . )
255 / 396
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).
256 / 396
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 )
257 / 396
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
258 / 396
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
259 / 396
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
260 / 396
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)
261 / 396
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.
262 / 396
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 ?
263 / 396
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
!!
264 / 396
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
265 / 396
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).
266 / 396
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
267 / 396
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
268 / 396
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.
269 / 396
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.
270 / 396
Outline
Terminologie
Matrice-Vecteur
271 / 396
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
272 / 396
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)
273 / 396
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
274 / 396
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
275 / 396
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
276 / 396
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.
277 / 396
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.
278 / 396
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
279 / 396
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
280 / 396
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
281 / 396
Outline
Terminologie
Matrice-Vecteur
282 / 396
283 / 396
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
284 / 396
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]
285 / 396
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]
286 / 396
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
287 / 396
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
288 / 396
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
289 / 396
Outline
Terminologie
Matrice-Vecteur
290 / 396
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)
291 / 396
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.
292 / 396
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
293 / 396
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
297 / 396
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.
298 / 396
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.
299 / 396
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.
300 / 396
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)
301 / 396
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).
302 / 396
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).
303 / 396
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.
304 / 396
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)β
305 / 396
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β
306 / 396
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
307 / 396
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.
308 / 396
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β
309 / 396
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.
310 / 396
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.
311 / 396
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.
312 / 396
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.
313 / 396
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.
314 / 396
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).
315 / 396
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
316 / 396
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
.
317 / 396
Illustration du placement statique
Figure : Parallélisation statique du produit matrice-vecteur sur réseau
hétérogène
318 / 396
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
319 / 396
Illustration du placement dynamique
Figure : Exemple de parallélisation dynamique du produit matrice-vecteur
par liste centralisée
320 / 396
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”
321 / 396
Outline
Terminologie
Matrice-Vecteur
322 / 396
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.
323 / 396
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 )
324 / 396
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
325 / 396
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
326 / 396
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
327 / 396
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)×τ
328 / 396
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 ×τ
329 / 396
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
330 / 396
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).
331 / 396
Outline
Informatique distribuée et Grid Computing
Informatique distribuée et système
Applications distribuées
Répartition des calculs
Représentation d’un calcul réparti
Abstractions de niveau plus élevé
Grid computing - Internet Computing
Classification et exemples de grilles de calcul
GridRPC - les projets DIET et Netsolve
Exemple d’utilisation de la grille : projet Grid-TLSE
332 / 396
Outline
333 / 396
point d’accés
interface
application
système de communication
OS
OS
OS
ordinateur
ordinateur
ordinateur
Réseau de communication
Figure : Composants d’un système informatique.
334 / 396
Notion d’interface
I
I
Ensemble des fonctions accessibles aux utilisateurs d’un service
Chaque fonction est définie par :
I
I
I
son format et sa syntaxe : mode d’emploi
sa spécification : son effet
Principe de base dans le développement d’un service : séparation
entre sa réalisation et son interface
I
I
Description de l’interface indépendante de sa réalisation
Avantages : facilite la portabilité (passage à une autre
implantation du service)
335 / 396
Rôle d’un système d’exploitation
Système fournit une interface avec la matériel :
I
Dissimule détails de mise en œuvre
I
Dissimule limitations physiques (taille mémoire, #processeurs)
et partage des ressources
→ machine virtuelle
I
Gestion des processus
I
Gestion de la mémoire
I
Gestion des communications
I
Gestion des accés (protection, droits d’accés)
336 / 396
Outline
337 / 396
Terminologie
On distingue :
I
Données ou traitements répartis ou distribués : la mise en œuvre
d’une opération nécessite d’utiliser plusieurs machines
I
Traitement coopératif : dialogue entre deux applications pour
réaliser une tâche
I
Interopérabilité : capacité des systèmes à partager des données
ou des traitements via des interfaces standards (systèmes ouverts
aptes à communiquer dans un environnement hétérogène).
338 / 396
Classes d’applications réparties
I
Coordination d’activités
I
Communication et partage d’information : bibliothèques
virtuelles
Travail coopératif :
I
I
I
I
I
Applications Temps Réel :
I
I
I
I
Calcul réparti et Grid-Computing
Edition coopérative
Téléconférence
Contrôle de procédés
Systèmes embarqués (avionique, . . . )
Localisation de mobiles
Services grand publics :
Presse électronique, Commerce électronique, . . .
339 / 396
Répartition vs parallélisme
Répartir les traitements (ou les distribuer) sur les machines les plus
adaptées n’implique pas que les traitements seront effectués en
parallèle.
Mais répartir les traitements est aussi une façon de les paralléliser.
340 / 396
Outline
341 / 396
La répartition [13]
Définition :
La répartition est la mise à disposition d’un ensemble de ressources et
de services connectés via un réseau pour tous les usagers possédant
un droit d’accès en un point quelconque.
342 / 396
Problème de la répartition
I
Problématique née avec l’idée de faire communiquer des
machines via un réseau, par exemple avec des échanges de
message
I
Développement et programmation d’applications réparties →
langages, systèmes d’exploitation, environnements
Difficultés à développer une application répartie :
I
I
I
I
I
I
Pas d’état global (état d’une autre machine ?)
Pas d’horloge globale (horloge propre à chaque machine)
Fiabibilité toute relative (certaine tolérance aux défaillances)
Sécurité relative (plus diffcile à protéger qu’une architecture
centralisée)
Non-déterminisme dans l’exécution des appplications
343 / 396
Avantages de la répartition
I
Partage de ressources et de services
Exemple : gestion de fichiers répartis service de base des
systèmes d’exploitation répartis
I
Répartition géographique : répartition essentielle pour accéder
aux moyens locaux nécessaires tout en gardant accès aux
ressources et services distants
I
Puissance de calcul cumulée, disponibilité, flexibilité
344 / 396
Algorithmique répartie
I
Problèmes bien spécifiques posés par les architectures réparties
I
Définition de protocoles de communication point-à-point et de
diffusion → formalismes de description (automates
communicants, réseaux de Pétri, . . . ) et outils d’aide à la
validation. Quelques standards existent (appels de procédure à
distante) mais protocoles souvent adaptés à une classe
d’applications.
I
Problèmes généraux (exclusion mutuelle, interblocage, atomicité,
réplication, . . . ) ou issus de la répartition des traitements et des
données (terminaison d’une application, réalisation d’un
consensus, . . . )
345 / 396
Langages de programmation
I
I
A priori une interface de programmation (API ) permettant
échange de message devrait suffire (e.g. sockets)
Introduction de structures de contrôle pour faciliter la
programmation :
I
I
non-déterminisme en réception avec possibilités d’associer à
chaque type de message attendu une action spécifique
Appel de procédure à distance (modèle client-serveur) : problème
il faut introduire un langage de définition de l’interface (IDL)
pour appeler les procédures distantes → génération automatique
du traitement des appels côté client et serveur.
346 / 396
Outline
347 / 396
I
Application structurée en un ensemble fixe de processus
I
Processus communicant : unité de répartition
Communication par messages :
I
I
I
Echanges de messages via canaux logiques point à point
(asynchrones, uni/bidirectionels, FIFO i.e. respectant la
chronologie d’envoi en réception, . . . )
Peut être représenté sous forme de graphe (sommets = processus,
arêtes = canaux)
348 / 396
p2
c1
p1
c6
c4
c2
p4
p3
c5
Figure : Exemple de représentation graphique d’un calcul réparti.
349 / 396
r2
e1
p1
e4
e5
p2
p3
r1
e2
P4
e3
0
t
Figure : Exemple de chronogramme.
I
I
I
I
(e1,r1) message point à point
diffusion avec émission e2
perte de message e3
...
350 / 396
I
Calcul réparti représenté sous forme d’un ensemble d’évènements
produits par chaque processus (évènements internes ou envois ou
réceptions de messages).
I
Les évènements issus de processus différents ne sont pas
forcément ordonnés mais ordre partiel induit par les messages
échangés.
I
Ordre partiel fondé sur une relation de causalité.
Relation notée ≺ satisfaisant :
I
1. Pour tout couple d’évènements (e,e’) issu d’un même processus
telque e précède e’ dans la suite associée au processus e ≺ e’.
2. Pour un échange de message entre 2 processus (envoi = e et
réception r), on a e ≺ r.
351 / 396
Protocoles ordonnés: exemple de liaison causale en
émission
p1
p2
p3
e1
e
m
r
e2
m1
m2
r2
r1
t
0
Message m1 reçu après m2 par le processeur p3, alors que un lien
causal existe en émission : e1 ( ≺ r ≺ ) e2 .
on risque de devoir forcer l’attente du message m1 pour traiter le
message m2.
352 / 396
Protocoles ordonnés évitant ce type de problème
I
Protocole ordonné d’ordre causal assure la propriété suivante
pour toute destination S :
∀m, m0
I
vers
S
:
em ≺ em0 ⇒ rm ≺ rm0
Diverses implantations de ces protocoles sont possibles.
353 / 396
Outline
354 / 396
I
I
Communication en mode message = niveau d’abstraction peu
élevé
D’où la proposition de mécanismes de communication plus
élaborés :
I
I
I
Appel de procédure à distance pour les traitements
Pour les données : communication par mémoire partagée ou par
fichiers partagés.
Notion de mémoire partagée répartie ou mémoire partagée
virtuelle ou mémoire partagée distribuée :
I
I
I
I
Objectif fournir un espace d’adressage global (modèle de
programmation centralisé) : LINDA, BBN, KSR, . . .
Difficulté de réalisation sur une architecture distribuée : éviter
une trop forte synchronisation des accès à cette mémoire
partagée répartie
Utilisation de la réplication → augmentation du parallélisme
d’accès à la mémoire
cohérence des copies !!!
Souvent implantation au dessus de transferts de messages
(hard/soft)
355 / 396
Mémoire partagée virtuelle
site A
site B
site C
objets partagés
Figure : Mémoire partagée virtuelle.
356 / 396
Approches
I
Modèles à cohérence faible : BBN
I
Modèles basés sur un mécanisme de cache ou de pagination
mémoire avec répertoires distribués : KSR, Convex SPP, . . .
Modèles à espace de tuples :
I
I
I
I
Base de données (tuples) partagée
Modèle de programmation à la Linda (dépôt, retrait et
consultation d’objets)
Exemple : JavaSpaces
357 / 396
Approches
I
Modèles à objets répartis partagés
I
I
I
I
I
Espace d’objets répartis partagés
Langage à objets extension d’un lange existant : expression de la
distribution, parallélisme, synchronisation, . . .
Désignation universelle d’objets
Gestion du partage des objets : synchronisation, cohérence
(image unique d’un objet ↔ copies cohérentes)
Divers modes de réalisation
I
I
Objets répliqués (Javanaise)
Objets à image unique (Guide)
358 / 396
Outline
359 / 396
Internet peut servir de support à l’exécution d’applications réparties
en plus de sa fonction d’accès à l’information.
Intérêt
I
I
Interface familière
Disponibilité d’outils de base :
I
I
I
I
Espace universel de désignation (URL)
Protocole de transfert de l’information (HTTP)
Gestion d’information sous format standard (HTML)
Web = système d’exploitation primitif pour application réparties
?
360 / 396
Internet peut servir de support à l’exécution d’applications réparties
en plus de sa fonction d’accès à l’information.
Problèmes
I
Où et comment sont exécutés les services ?
I
Comment trouver les services ?
Comment assurer la sécurité ?
I
I
Problème majeur non résolu
I
I
I
I
Protection des sites
Encryptage de l’information
Restrictions sur les conditions d’exécution
Traçabilité:
mais finalement qui bénéficie du résultat l’exécution du service?
361 / 396
Caractéristiques d’une Grille
I
Coordination de ressources non assujetties à un contrôle
centralisé
I
I
I
I
Répartition à grande échelle
Utilisateurs dans des domaines administratifs distincts
D’où problèmes de sécurité, authentification, délégation,
facturation, . . .
Utilisation de protocoles et d’interfaces génériques, ouverts,
standardisés (inter-opérabilité)
I
Grille = ensemble d’interfaces et de protocoles portant sur
authentification, découverte, autorisation et exploitation des
ressources
I
Divers niveaux de qualité de service (temps de réponse, débit,
disponibilité, sécurité, co-allocation de ressources, . . . )
I
Forte variation de la qualité de service
362 / 396
Qu’est-ce qui n’est pas une grille ?
I
Grilles = partage de ressources dynamiques entre organisations
virtuelles
I
Les approches utilisées pour les applications distribuées n’offrent
pas un environnement de partage de ressources général (e.g.
autentification, délégation, monitoring, ordonnacement,
inter-opérabilité, . . . )
I
Par exemple CORBA : partage de ressource relativement statique
et interne à une organisation. Plutôt orienté client-serveur
Avec CORBA + technologie grille :
I
I
I
I
Object Request Broker permettant de gérer les requêtes entre
organisations différentes,
Portable Object Adaptator accédant aux ressources d’un
organisation virtuelle.
Services nommage et de courtage niveau grille et inter-opérabilité
avec des clients non CORBA.
363 / 396
Divers types de grille
I
Grilles de partage et/ou de traitement de l’information
I
Exemples :
I
I
I
I
Partage de la connaissance sur le Web
Grilles bio-médicales : télé-médecine, analyse médicale
Formation à distance
Grilles de stockage
I
I
I
I
I
I
Exploitation de l’espace libre disponible sur une grille
Stockage à grande échelle
Stockage de gros volume
Stockage fiable
Stockage anonyme
Exemples : DataGrid, Kazaa, Gnutella, Us
364 / 396
Grilles de calcul :
I Agréger de la puissance de calcul ou permettre le couplage de
codes ou de modules de traitement (BD, calcul, visualisation)
I
Intergiciels construits sur les concepts de:
I
I
I
I
I
I
I
GRID-RPC : Remote Procedure Call pour la grille
ASP: Application Service Providers - Client-Serveur
DOA : Distributed object Oriented Architectures
Composants logiciels
Plateformes générales,
orientées soumission de BATCH (ex: UNICORE) ou interactif
ciblant des domaines : astronomie, nucléaire, simulation
moléculaire, grilles bio-médicales . . .
365 / 396
Outline
366 / 396
Grilles de calcul : tentative de classification (Th. Priol,
INRIA)
I
Multiplicité de termes : P2P Computing, Metacomputing,
Virtual Supercomputing, Desktop Grid, Pervasive Computing,
Utility Computing, Mobile Computing, Internet Computing, PC
Grid Computing, On Demand Computing, . . .
I
Virtual Supercomputing : grilles de supercalculateurs ;
I
Desktop Grid, Internet Computing : grille composée d’un très
grand nombre de PC (10,000 - 1,000,000);
I
Metacomputing: association de serveurs applicatifs;
I
P2P Computing : infrastructure de calcul Pair-à-Pair:
chaque entité peut être alternativement client ou serveur.
367 / 396
Vision de la “grille aux USA”.
368 / 396
Peer-to-Peer : SETI@home
I
I
I
I
I
I
I
500,000 PCs à la recherche d’intelligence extra-terrestre
Analyse du signal
Pair récupère un jeu de données depuis le radio-téléscope
d’Arecibo
Pair analyse les données (300 kB, 3TFlops, 10 hours) quand ils
sont inactifs
Les résultats sont transmis à l’équipe SETI
35 TFlop/s en moyenne
Source d’inspiration pour de nombreuses entreprises
369 / 396
Peer-to-Peer : SETI@home
Users
Results received
Total CPU time
Flops
I
I
I
I
I
I
I
Total
5436301
2005637370
2378563.061 years
7.406171e+21
Last 24 Hours
0 new users
780175
539.796 years
3.042682e+18
500,000 PCs à la recherche d’intelligence extra-terrestre
Analyse du signal
Pair récupère un jeu de données depuis le radio-téléscope
d’Arecibo
Pair analyse les données (300 kB, 3TFlops, 10 hours) quand ils
sont inactifs
Les résultats sont transmis à l’équipe SETI
35 TFlop/s en moyenne
Source d’inspiration pour de nombreuses entreprises
370 / 396
Google (d’après J. Dongarra)
I
2600 requêtes par seconde (200 × 106 par jour)
I
100 pays
I
8 × 109 documents indexés
I
450,000 systèmes Linux dans plusieurs centres de données
I
Consommation électrique 20 MW (2 millions de $ par mois)
I
Ordre d’apparence des pages ⇔ valeurs propres d’une matrice de
probabilité de transition (1 entre page i et j signifie l’existence
d’un lien de i vers j)
371 / 396
Outline
372 / 396
RPC et Grid Computing : Grid RPC (F. Desprez, INRIA)
I
Idée simple:
I
I
I
I
Construire le modèle de programmation RPC sur la grille
utiliser les ressources (données+services) disponibles sur le réseau
Parallélisme mixte : guidé par les données au niveau du serveur et
par les tâches entre les serveurs.
Fonctionnalités requises:
1. Equilibrage de charge (localisation services, évaluation de
performance, séquencement)
2. IDL (Interface Definition Language)
3. Mécanismes pour gérer la persistence et la dupplication des
données.
4. Sécurité, Tolérance aux pannes, Interopérabilité entre intergiciels
373 / 396
RPC et Grid Computing : Grid RPC (suite)
I
Exemples:
I
I
Netsolve (Univ. Tennessee) (le plus ancien, basé sur des sockets)
DIET: Projet Graal, INRIA.
Outil récent largement utilisé
Travaux importants sur l’équilibrage/gestion données.
374 / 396
NetSolve (1) : H. Casanova, J. Dongarra, . . .
I
I
Objectif : donner un accès uniforme et efficace à des ressources
(softs scientifiques) sur une large gamme de plateformes (UNIX
et Windows)
Mécanismes de base :
I
I
I
I
I
I
Modèle Client-Serveur
Organisation non-hiérarchique
Equilibrage des tâches et tolérance aux fautes
Environnement hétérogène
Plusieurs interfaces client disponibles : Fortran, C, Matlab, Java,
Mathematica, . . .
Mécanismes de base standards (RPC, . . . )
375 / 396
NetSolve (2)
Organisation de NetSolve [4].
376 / 396
NetSolve (3)
I
Accés à des ressources sur Intranet, Internet, . . .
I
Utilisation : “méta-calculateur”
I
Serveurs locaux configurés à la demande (ajout / sélection des
ressources)
I
Environnement d’exécution répartie ?
Quelques caractéristiques :
I
I
I
I
I
Accés aux ressources sur le Net transparent
Localisation des traitements tranparente
Facilite la maintenance des logiciels
Requètes (appels de procédures) synchrones ou asynchrones et
“farming” → exploitation d’un niveau de parallélisme
377 / 396
NetSolve (4) : Interface Matlab
I
Appel bloquant :
>>
>>
I
load a
[x y] = netsolve(’eig’,a)
....
Appel non bloquant :
>> load a
>> [r] = netsolve_nb(’send’,’eig’,a)
Contacting server xxxxx
r = 0
...
>> [status] = netsolve_nb(’probe’,r)
Not ready yet
status = -1
...
>> [status] = netsolve_nb(’probe’,r)
Result available
status = 0
>> [x y] = netsolve_nb(’wait’,r)
...
378 / 396
Agent - Serveur NetSolve
I
Agent :
I
I
I
Localise les serveurs de calcul
En charge de l’équilibrage des traitements
Serveur :
I
I
Ensemble de logiciles sur des plateformes différentes (stations,
clusters, MPP, . . . )
Configurable et extensible :
I
I
Possibilité d’ajouter des services
BLAS, LAPACK, ScaLAPACK, . . . pré-installés
379 / 396
Quelques difficultés qui émergent au passage . . .
I
Logiciels qui nécessitent une fonction codée par l’utilisateur :
I
I
Traitements parallèles : requête à une procédure de calcul MPI
sur un cluster de PC
I
I
Softs d’optimisation par exemple (ex: NEOS)
NetSolve s’occupe de lancer l’environnement MPI, de la
distribution des données, et du retour des résultats
Transferts des données :
I
I
Utilisation d’un codage type RPC : transfert systématique des
paramètres d’entrée et de sortie → inutilement couteux lors de
requètes successives incluant la même matrivce par exemple
Analyse data-flow : mécanisme de cache des données sur les
serveurs de calcul, évaluation paresseuse (Legion) ?
380 / 396
Remarques
Il y a une différence entre
(1) répartir un ensemble d’applications sur une grille et
(2) distribuer une application sur une grille
(1) devrait impliquer que chaque application est capable d’exploiter
les ressources (parallélisme) de chacun des noeuds de la grille.
381 / 396
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
Distributed Systems
- Gather (unused) resources
- Steal cycles
- System SW manages resources
- 10% - 20% overhead is OK
- Resources drive applications
- Time to completion is not
critical
- Time-shared
- Heterogeneous
382 / 396
Outline
383 / 396
Un site Web pour l’expertise en Algèbre linéaire :
gridtlse.org
I
3-year project funded by ACI GRID program
from the French Ministry of Research
(January 2003 −− > January 2006)
(http://www.enseeiht.fr/lima/tlse)
I
Research Labs : CERFACS and IRIT (Toulouse), LaBRI
(Bordeaux), LIP-ENS (Lyon)
I
Industrial partners :
CNES, CEA, EADS, EDF, IFP
I
International links : Berkeley, RAL, Parallab, Univ. Florida,
Univ. Minneapolis, Univ. Minnesota, Univ. Tennessee, Univ.
San Diego, Univ. Indiana, . . .
384 / 396
Goals
I
Design a Web expert site for sparse matrices
I
Limit the study to sparse direct solvers
I
Disseminate the expertise
I
Provide an interface to experiment software
- public . . . as well as commercial
- sequential . . . as well as parallel
I
Submit a matrix or use matrix collections
I
Provide tools to help incorporating new services
385 / 396
Example of expertise request
I
Assumption : The performance (time and memory used) of our
solvers depends mostly on the choice of the ordering used.
I
Examples of request:
I
I
I
Memory required to factor a matrix
Error analysis as a function of the threshold pivoting value
Minimum time on a given computer to factor a given
unsymmetric matrix ?
386 / 396
GRID computing ?
I
Each request involves a large number of elementary requests
(e.g. as many simultaneous executions of a sparse package as
available orderings or more generally appropriate values of input
parameters)
I
Choice of target computers depends on type of request: (Matrix
availability, Memory requirement, CPU requirement, software
availability, cost of computing time . . .)
I
Grid of moderate size where each elementary request will run on
one node (mono or multiprocessor) of the Grid.
387 / 396
Is it realistic ?
I
Independency of elementary requests
I
Results from experiments : synthetic data
(the expert site is not a computing engine)
I
Time to answer is not so critical
I
Data persistency between elementary requests easier to express
388 / 396
Main components of the site
I
Sparse matrix software: direct solvers
I
I
I
I
I
I
MUMPS (CERFACS, IRIT, LIP-ENS)
PaStiX, SCOTCH (LaBRI)
HSL (RAL) Library
SuperLU (Berkeley), UMFPACK (Univ Florida)
Others . . .
Database:
I
I
I
Bibliography
Sparse matrix collections (RAL-BOEING, PARASOL,
user-provided)
Experimental results
389 / 396
Grid Infrastructure
I
Use of middleware developed within the GRID ASP project
(LIP-Graal, LORIA-Résédas, LIFC-SDRP) : DIET
I
High-level administrator interface for the definition, the
deployment, and the exploitation of services over a grid : Weaver
I
Interactive Web interface with the Grid: WebSolve
I
We do not provide computational resources, we just perform
expertise (i.e. we may only report statistics on using various
software on a matrix)
390 / 396
Software components
External User
Expert Site :
Internal User
Expert
Grid−TLSE
/ ...
WebSolve
Database
Weaver
History
Logfiles
MIDDLEWARE
(DIET/FAST)
Stats
Collect.
Matrices
Static
Bibliography
Dynamic
( RAL−BOEING / Parasol )
User−supplied matrices
Solvers
Grid
391 / 396
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.
H. Casanova, J. J. Dongarra, A. Karaino, and J. Wasniewski.
User’s guide to netsolve version 1.2.beta.
392 / 396
Technical Report TN 37996, University of Tennessee, USA, 1998.
J. J. Dongarra, J. J. Du Croz, S. Hammarling, and R. J. Hanson.
An extented set of Fortran Basic Linear Algebra Subprograms.
ACM Transactions on Mathematical Software, 14:17 and 18–32,
1988.
J. J. Dongarra, Iain S. Duff, D. C. Sorensen, and H. A. van der
Vorst.
Solving Linear Systems on Vector and Shared Memory
Computers.
SIAM, Philadelphia, 1991.
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.
393 / 396
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.
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.
394 / 396
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.
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.
395 / 396
Also available as University of Tennessee LAPACK Working Note
#147, UT-CS-00-448, 2000
(www.netlib.org/lapack/lawns/lawn147.ps).
396 / 396

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

Transcription

Documents pareils

Mise en avant Les atouts Spécifications principales

FT MPI 11-00B.CDR

Le Travail de Mémoire - France-Crashes 39-45

Spécifications détaillées

Agent Call Center Inbound 70% à 80%

cours plus détaillé

Environnement Logiciel pour le calcul scientifique

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

Notice du jeu MOV - Orthophonie et Logiciels Libres