Code Saturne (thermohydraulique monophasique)

Retours BlueGene/L
S. Kortas & C. Domain
EDF R&D
Mai 2005
Machines testées
IBM BlueGene/L : 1 rack, 2000 PowerPC 440, 0.77 GHz, 2.7
GF/s
Cluster OPTERON (Tantale) : 552 proc OPTERON, 2.2 et
2.4 Ghz
COMPAQ SC45 : 880 proc, EV68, 1.25 GHz (2.5 Gflops/s)
2
12/04/2006
Code Saturne (thermohydraulique monophasique)
Code Saturne : a EDF general purpose CFD code for
refined flow modelling
Cas-test : modèle de turbulence k-ε standard, 2 millions
cellules, 5 millions faces internes
Calculateurs testés : IBM BG/L (mode Coproc et Virtuel),
COMPAQ SC45 et Cluster Opteron.
Compilation C
qmaxmem=-1.
3
12/04/2006
(BG/L):
-O3
-qarch=440
-qtune=440
-
Code Saturne (thermohydraulique monophasique)
Speedups:
Chrome: 55 sur 128
Tantale: 110 sur 128
BG/L: 614 sur 1024
4
12/04/2006
Code Saturne (thermohydraulique monophasique)
Conclusions
< 512 processeurs : mode virtual est 5% moins bon que mode
coproc
Mesures de performances :
• Un proc OPTERON 2,2Ghz = 2 proc BlueGene/L,
• Un proc SC45 1,25 Ghz = 3 proc BlueGene/L
• Efficacité (beaucoup IO, cas relativement petit) :
• 76% à 512 procs,
• 61% à 1000 proc
5
12/04/2006
Code Zephyr
Caractéristiques des tests
• Résolution des équations de Burgers visqueux 2D en Volumes finis d’ordre
2
• Partitionnement de domaine
• Gradient conjugué BiCGSTAB avec de nombreuses communications et
réductions
• Problème 1024² et 512² résolu sur 1, 2 , 4, … 1024 proc Æ efficacité
parallèle
• Problème 256² x (nb processeurs) résolu sur 1, 4, 16, 64 procs Æ
scalabilité
• Machines : chrome, tantale, IBM BG/L
• Performances rapportée au temps d’une itération
Déroulement du portage :
• Antécédent : code déjà porté sur IBM SP2
• Aucun problème de compilation ni d’exécution
• Utilisation d’une routine de chronométrage spécifique à IBM BG/L
6
12/04/2006
Code Zephyr /Performance BG/L
BGL 1024² / coproc vs virtual
1024² copro
1024² virtual
lineaire
BGL 1024² / comparaison scalabilité
# proc
# proc
1
10
100
1000
1
10000
1,00E+00
10
chrome
tantale
BG/L copro
BG virtual
100
1000
1,2
1
1,00E-01
scall //
time (s)
0,8
1,00E-02
0,6
Bon réseau sur BG/L
0,4
1,00E-03
Efficacité // > 90 % jusqu’à 128 proc en mode Copro
Forte pénalisation des communications en virtual mode
0,2
1,00E-04
0
BG/L coproc vs virtual mode
512²
# proc
1
10
BG/L scalabilité parallèle
1024²
100
1000
1
160,00%
10
scal virtual
100
1000
1,2
140,00%
1
120,00%
100,00%
80,00%
60,00%
40,00%
20,00%
0,00%
7
0,8
Pb estimation
comm/calcul
pour un cas
donné
12/04/2006
// eff
t(virtual)/t(copro
scal copro
# proc
Différence de 2 à 38 %
entre virtuel et copro
comportement difficilement
prévisible?
0,6
0,4
Scalabilité quasi-idéale en copro
Scalabilité de 80 % en mode virtuel
0,2
0
Speedup super-linéaire!
Code DYMOKA
Caractéristiques des tests
• Dynamique moléculaire classique dans les métaux – intégration de équation
de Newton utilisant un potentiel de type EAM (potentiel local avec un rayon de
coupure vers les 3ème ou 5ème voisins typiquement) – algorithme linéaire avec
la taille du système – parallélisation : décomposition de domaine avec MPI
• Dynamique moléculaire dans du Fer bcc
• Performance mesurée en temps de calcul par atome et par pas de
d’intégration (l ’algorithme étant linéaire)
Déroulement du portage :
• Antécédent : code déjà porté sur IBM SP2, ainsi que de nombreuses
machines parallèles depuis 10 ans.
• Aucun problème de compilation
• les options de compilations améliorent peu les performances, de l ’ordre de
1%
• Utilisation de la routine MPI_WTIME()
8
12/04/2006
Code DYMOKA /Performance BG/L
•Pas de différence entre coproc et virtual mode
•Le scaling est linéaire à au moins 98% jusqu’à 1024 processeurs,
avec un système de plusieurs 10 millions d’atomes
•Le temps de calcul est constant et est égal à 47 µs /atom /step
•Le temps de calcul sur N procs est donc de (47 / N) µs /atom/step
•Aucun effet de cache n’a été observé
9
12/04/2006
Code DYMOKA / Comparaison BG/L vs Chrome
Nickel
cas box 30x30x30 = 54000 atomes
n procs
temps/atom/step (µs)
1
2
4
8
16
32
17,945
9
4,7152
2,55
1,29
efficacite
Machine
0,99694444
0,95144427
0,87965686
0,86942829
Sur le même problème,
BG/L garde une efficacité > 98%
10
12/04/2006
Comparaison
Nickel
BGL
temps/atome/step (µs)
36
47
Un processeur BGL est 30% plus lent
qu’un Alpha EV 68
Code VASP (code ab initio DFT)
Caractéristiques des tests :
• Calcul Ab Initio – théorie de la fonctionnelle de la densité (DFT) – description
des interaction électron-ion avec des pseudo-potentiels ultradoux de type
Vanderbilt et utilisation d’une base d’ondes planes.
• Cas Zr8H: supercellule avec 8 atomes de Zr structure hcp et 1 atome
d’hydrogène
• Cas GaN : maille de 8 atomes (4 de Ga et 4 de N) de structure zincblinde
• Tel quel par défaut le code a besoin de plusieurs centaines de Mo de RAM
par CPU et donc aucun gros calcul n ’a pu être lancé
Déroulement du portage :
• Antécédent : code déjà porté sur IBM SP2
• Aucun problème de compilation majeur
• les indentations au niveau des #ifdef #else #endif ne sont pas supportées
• option 440d ne fonctionne pas
• Aucune optimisation n’a été faite sur la parallélisation par rapport aux
spécificité de BGL
11
12/04/2006
Code VASP /Performance BG/L
Cas Zr8H
nproc
VASP - BGL - Efficacité
Temps CPU ( Efficacité
1
2
4
8
16
691,4
364,2 0,94920373
206,9 0,83542774
163,1 0,52988964
Speedup de 8,5 sur 16
Cas GaN
1
0,9
0,8
0,7
0,6
0,5
0,4
cas GaN
0,3
cas Zr8H
0,2
0,1
0
N proc
2
4
8
16
32
Temps CPU ( Efficacité
692,1
390 0,88730769
251,4 0,68824582
228,3 0,37894218
277,5 0,15587838
Speedup de 5 sur 32
12
12/04/2006
1
cas Zr8H
2
4
8
cas GaN
16
Mauvaise scalabilité pour
Un grand nombre de processeurs
Code VASP / Comparaison BG/L vs Chrome et
Tantale
VASP - cas "GaN"
VASP - cas "Zr8H"
700
700
600
600
500
500
400
Alpha
400
Opteron
300
Opteron
300
Alpha
200
BGL
200
BGL
100
100
BGL
Opteron
0
1
2
4
Alpha
8
BGL
Alpha
0
1
2
4
16
VASP: performance 2 CPU BG/L ~ 1CPU Operon ~ 1 CPU Alpha
13
12/04/2006
Opteron
8
16