Extensions d`OpenMP pour les Architectures a Hi

RENPAR/CFSE/SYMPA
Paris, cite des sciences et de l'industrie, 24 { 27 avril 2001
Extensions d'OpenMP pour les Architectures a Hierarchie
Memoire Multiple
Fr
ed
eric Br
egier, Barbara Chapman, Amit Patil, Achal Prabhakar
University of Houston, Computer Science Department,
Philip. G. Homan Hall, 4800 Calhoun Street, Houston Texas, 77204-34775 - USA
[email protected], [email protected]
Resume
Dans cet article, nous pr
esentons des exp
erimentations portant sur un ensemble de programmes repr
esentatifs de probl
emes rencontr
es lors de la programmation avec le langage OpenMP d'architectures du
type NUMA, architectures a
m
emoire distribu
ee et grappes de noeuds a
m
emoire partag
ee (architectures
a
hi
erarchie m
emoire multiple). Nous y soulignons l'importance pour la performance de prendre en compte
la localit
e des donn
ees a
l'aide du concept de privatisation des donn
ees. Comme l'
ecriture a
l'aide de ce
concept de tels codes en OpenMP n'est pas ais
e, nous proposons e
galement un ensemble d'extensions a
OpenMP utilisant essentiellement le concept de distribution en s'inspirant de HPF. Nos exp
erimentations
portent sur deux types d'architectures, une machine cc-NUMA avec un SGI Origin 2000, et une architecture
a
m
emoire distribu
ee avec un IBM SP2 en utilisant une approche de m
emoire partag
ee r
epartie logicielle
avec la biblioth
eque TreadMarks.
Mots-cles : OpenMP, Architecture NUMA, Memoire partagee repartie logicielle, Privatisation, HPF
1. Introduction
OpenMP [3] propose un standard pour la programmation parall
ele d'architectures a
m
emoire partag
ee. Il
propose une approche relativement simple pour cr
eer des codes parall
eles, permettant en particulier un
d
eveloppement incr
emental de codes parall
eles depuis des codes s
equentiels existants.
Mais il est extr^
emement dicile de construire des syst
emes a
m
emoire r
eellement partag
ee de taille
quelconque. Ainsi les syst
emes actuels peuvent avoir 16 processeurs connect
es a
la m
emoire partag
ee, et
des syst
emes a
32 processeurs devraient bient^
ot e
^ tre disponibles. Leur bus partag
e entre les processeurs et
la m
emoire repr
esente une r
eelle limitation. Pour solution, certains constructeurs proposent des machines
constitu
ees d'un certain nombre de noeuds, chacun ayant sa propre m
emoire partag
ee interne ; ces
noeuds sont connect
es de facon a
cr
eer une plate-forme extensible avec un acc
es a
la m
emoire non
uniforme (NUMA). Si un tel syst
eme a un espace d'adressage global et si le mat
eriel supporte une
coh
erence de cache sur l'ensemble de la machine, OpenMP peut e
^ tre impl
ement
e sur ce syst
eme.
De plus, il y a un int
er^
et croissant a
programmer des machines a
m
emoire partag
ee en grappes, ou
m^
eme des machines a
m
emoire distribu
ee comme un simple super-calculateur en utilisant par exemple
un syst
eme de m
emoire partag
ee r
epartie par support logiciel (SDSM en anglais). Cependant, OpenMP
n'a aucun dispositif pour supporter l'optimisation des codes sur des syst
emes NUMA, et il n'est pas non
plus un bon candidat comme mod
ele de programmation pour de tels syst
emes NUMA e
tendus, puisqu'il
ne peut pas s'
etendre au-del
a d'un espace d'adressage unique.
Dans la suite, nous pr
esentons d'abord un ensemble d'extensions a
OpenMP (section 2) qui est destin
e
a
am
eliorer l'ex
ecution sur des syst
emes NUMA et qui pourrait e
galement e
^ tre mis en application a
travers un syst
eme a
m
emoire distribu
ee (par l'interm
ediaire de SDSM ou de techniques de compilation
emprunt
ees a
HPF [8]). Ces extensions utilisent principalement le concept de la privatisation de donn
ees.
Nous pr
esentons des exp
eriences montrant l'int
er^
et de cette approche sur deux architectures (section 3),
une machine cc-NUMA avec un Origin 2000 de SGI, et une machine a
m
emoire distribu
ee avec un IBM SP2
en utilisant une approche SDSM avec TreadMarks [13, 1]. Ces exp
eriences (section 4) sont repr
esentatives
de probl
emes li
es a
la programmation d'architecture a
hi
erarchie m
emoire multiple. La section 5 pr
esente
les travaux relatifs a
cette e
tude.
2. Programmation d'architectures NUMA
An d'^
etre ecace, le programmeur doit faire attention a
la hi
erarchie m
emoire de l'architecture sousjacente. Ainsi, on peut e
crire un programme dans un style SPMD employant la privatisation des donn
ees
de facon a
placer toutes les donn
ees dans un niveau de m
emoire aussi proche que possible du processeur.
Mais cette approche est dicile et exige une attention sp
eciale puisque le code n'est plus li
ea
la version
s
equentielle originale, et donc dicile a
maintenir, d
evelopper ou d
eboguer.
Pour faciliter l'eort de programmeur et rester aussi pr
es que possible de la version s
equentielle originale,
nous proposons un ensemble d'extensions a
OpenMP, appel
e NUMA-OMP pour produire automatiquement ces codes. Ces extensions sont principalement emprunt
ees a
HPF [8] et concernent le placement
des donn
ees et l'acc
es local aux donn
ees.
Nous proposons d'abord une directive DISTRIBUTE avec trois formats, ?, BLOCK et CYCLIC. Elle sp
ecie
comment les donn
ees sont plac
ees (privatis
ees) sur les m
emoires des processeurs.
La directive ON HOME permet, via le placement de la donn
ee sp
eci
ee dans la directive, d'indiquer quel
thread doit ex
ecuter le bloc d'instructions qui suit.
Nous proposons aussi d'employer la directive SHADOW pour sp
ecier quelles parties des tableaux distribu
es
vont e
^ tre acc
ed
ees non localement fr
equemment. L'utilisation de cette directive permet au compilateur
d'allouer un stockage compl
ementaire, des zones de recouvrement sur chaque processeur, an de permettre un acc
es local aux donn
ees voisines distantes.
ce jour, toutes nos exp
A
eriences sont faites a
l'aide de codes produits a
la main, mais nous projetons
d'obtenir directement ces codes en employant plus tard notre compilateur d'
etude. Nous emploierons
alors la sentinelle !$NMP pour indiquer les directives NUMA-OMP, comme suit (
a droite un pseudo code
indiquant l'
ecriture manuelle) :
real A(M,N), B(M,N)
!$NMP DISTRIBUTE B(*,BLOCK)
!$NMP DISTRIBUTE A(*,BLOCK)
!$NMP SHADOW A(0,1)
! NOT = nombre de threads
real A(M,0:N/NOT+1), B(M,N/NOT)
!$OMP PARALLEL DO
!$NMP ON HOME (A(:,I))
DO I = 1, N
B(:,I) = A(:,I-1) + A(:,I) + A(:,I+1)
END DO
!$OMP END PARALLEL
!$OMP PARALLEL
DO I = 1, N/NOT
B(:,I) = A(:,I-1) + A(:,I) + A(:,I+1)
END DO
!$OMP END PARALLEL
3. Architectures utilisees
Nous avons employ
e deux sortes d'architectures : d'une part une architecture cc-NUMA avec un SGI
Origin 2000 et d'autre part un syst
eme a
m
emoire distribu
ee combin
ea
un SDSM avec un IBM SP2.
3.1. Architecture cc-NUMA
Le mod
ele de programmation a
m
emoire partag
ee d
evelopp
e pour les SMPs (Symmetric Multi-Processor)
s'est av
er
e tr
es populaire, cependant les SMPs purs ne peuvent pas atteindre de grande taille en raison
du bus partag
e entre les processeurs et la m
emoire. Pour r
esoudre cela, les constructeurs ont concu des
syst
emes divis
es dans des modules plus petits. Chaque noeud est un SMP pur avec un r
eseau haut d
ebit
connectant tous les noeuds. De tels syst
emes ont un espace d'adressage m
emoire global et le mod
ele de
programmation a
m
emoire partag
ee s'applique. Ces machines sont aussi appel
ees des machines NUMA a
cause de la non-uniformit
e dans les temps d'acc
es a
la m
emoire distante et locale [19]. Les syst
emes qui
fournissent la coh
erence de cache sont appel
es cc-NUMA. Des exemples commerciaux incluent l'Origin
2000 de SGI et les AplhaServer GS80, GS106 et GS320 de Compaq.
2
L'Origin 2000 est constitu
e d'un r
eseau hypercube reliant chaque noeud (Fig. 1). Un noeud comporte
deux processeurs MIPS R12000, avec une portion de la m
emoire partag
ee. Chaque MIPS R12000 a deux
niveaux de cache associatifs. Le premier niveau de cache poss
ede 32Ko pour les donn
ees et 32Ko pour
les instructions. Le second niveau de cache poss
ede en g
en
eral 4Mo avec une taille de ligne de 128
octets. Tous les caches utilisent l'algorithme du moins recemment utilise (LRU), chaque noeud contiennent
au plus 4Go de m
emoire et est connect
ea
une portion du syst
eme d'entr
ee-sortie.
Node 0
Proc A
Proc B
Cache
Cache
Node 1
Mem
&
Dir
Hub
Node N
IO
Xbar
IO Ctrls
Scalable Interconnect Network
Figure 1. Architecture de l'Origin 2000 de SGI
Le mod
ele de programmation a
m
emoire partag
ee assume des temps d'acc
es uniformes pour l'espace
d'adressage entier. L'assimilation des machines NUMA au mod
ele SMP peut ne pas amener des performances optimales en raison de propri
et
es de localit
e spatiale inadapt
ees.
N
eanmoins, les syst
emes NUMA peuvent d
elivrer cette haute performance pour des applications bas
ees
sur la m
emoire partag
ee si le placement des donn
ees est local au processeur sur lequel le calcul est
ex
ecut
e. OpenMP lui-m^
eme ne fournit pas de facilit
e pour le placement des donn
ees, n
eanmoins on
s'attend sur des machines NUMA a
ce que la localit
e des donn
ees augmentant, les performances pour
les applications OpenMP augmentent elles aussi.
Comme SGI e
tait conscient des probl
emes de localit
e des donn
ees sur une machine NUMA, ils ont propos
e [10] plusieurs facons de distribuer les donn
ees (et les calculs en fonction des donn
ees), en employant
une politique de premier contact (\First Touch", le premier processeur acc
edant a
un e
l
ement d'une page
se verra attribuer cette page dans sa m
emoire locale) ou l'utilisation explicite de directives de distribution.
Bien que distribu
es, il faut noter que les tableaux demeurent toujours partag
es via le support fourni par
le syst
eme d'exploitation. La clause AFFINITY permet d'indiquer, tout comme la directive ON HOME, le
thread associ
ea
chaque it
eration.
Selon la documentation SGI, aucune distribution (First Touch) et la directive DISTRIBUTE sont presque semblables. La seule di e
rence est que la distribution via DISTRIBUTE est faite a
la compilation alors que le
First Touch a lieu a
l'ex
ecution. Par d
efaut, le compilateur OpenMP de SGI utilise le First Touch [5]. Bien s^
ur,
il faut tenir compte de ce premier acc
es pour distribuer correctement les donn
ees (et donc eectuer le
premier acc
es dans une r
egion parall
ele, sinon le processeur 0 poss
edera l'ensemble des pages associ
ees
aux donn
ees).
La directive DISTRIBUTE de SGI distribue a
la HPF les tableaux, mais elle emploie une distribution bas
ee
sur la pagination de la m
emoire (bas
ee sur la taille d'une page).
La directive DISTRIBUTE RESHAPE emploie une autre facon de distribuer un tableau, en se basant sur les
e
l
ements et non sur les pages. De ce fait, les tableaux sont r
eorganis
es et l'arithm
etique des pointeurs
est employ
ee pour acc
eder a
un e
l
ement. Cette facon de faire est tr
es semblable a
la version que nous
avons produite a
la main, except
e que le tableau reste toujours partag
e parmi les processeurs.
Nous avons donc mis en oeuvre pour chaque exemple 4 versions, une Sans Distribution, une avec un
la main appel
e Private.
DISTRIBUTE, une avec un DISTRIBUTE RESHAPE et nalement une produite a
Cette derni
ere est semblable au style de programmation SPMD. Les tableaux sont distribu
es sur l'ensemble
3
des processeurs et d
eclar
es priv
es. Nous employons chaque fois un buer partag
e de petite taille pour
r
ealiser les communications entre les threads. Ainsi les calculs de chaque thread portent uniquement
sur les parties priv
ees des tableaux et le partage est r
ealis
e a
travers ces petits buers partag
es. La
privatisation assure que les donn
ees \suppos
ees locales" seront eectivement allou
ees dans la m
emoire
locale du noeud o
u se situe le processeur, contrairement aux directives de distribution ou au First Touch,
o
u le syst
eme de gestion de la m
emoire partag
ee ne peut assurer qu'
a chaque ex
ecution la m
emoire
allou
ee sera r
eellement locale au processeur : dans un environnement multi-utilisateurs, la m
emoire du
noeud peut e
^ tre utilis
ee par d'autres processus tournant sur des noeuds voisins, impliquant alors que la
m
emoire associ
ee au programme s'ex
ecutant sur ce noeud soit en fait allou
ee sur un noeud distant.
Une autre possibilit
e est d'utiliser la migration automatique des pages propos
ee par le syst
eme d'exploitation de l'Origin 2000, o
u les donn
ees acc
ed
ees de mani
ere distante peuvent e
^ tre, de mani
ere
transparente, migr
ees sur une m
emoire proche du processeur qui l'a r
ef e
renc
ee. Mais nous avons rencontr
e de nombreux probl
emes dans la pratique avec cette technique, avec des performances toujours
tr
es inf e
rieures a
ce que nous obtenons en interdisant cette migration automatique.
Les exp
eriences ont e
t
e conduites sur l'Origin 2000 de SGI au NCSA. La conguration actuelle du NCSA
consiste en une machine de 48 processeurs nomm
ee modi4, et de 11 autres de 64 a
256 processeurs.
modi4 est disponible pour l'acc
es interactif, tandis que les autres machines sont utilis
ees via la soumission
de jobs. Chaque machine est homog
ene, mais pr
esentent des di e
rences : le type de processeur varie de
195MHz R10000 a
250MHz R10000 et la m
emoire globale varie entre 16 et 128 Go. Sur toutes ces machines,
le niveau 1 de cache pour les donn
ees et les instructions sont tous les deux de 32 Ko, tandis que le
niveau 2 de cache est de 4 Mo. Toutes nos exp
eriences ont e
t
e conduites dans un mode multi-utilisateurs.
Nous avons employ
e le compilateur MIPSPRO 7 Fortran 90 de SGI avec les options -mp -Ofast.
3.2. Memoire partagee repartie par support logiciel
Les syst
emes dans lesquels la coh
erence de la m
emoire est g
er
ee par un logiciel sont a
l'autre bout du
spectre des architectures a
m
emoire partag
ee. De telles machines consistent g
en
eralement en un certain
nombre de processeurs reli
es par un r
eseau rapide, o
u toutes les m
emoires sont physiquement distribu
ees
avec une couche logicielle imitant un espace d'adressage global. Les caract
eristiques de telles machines
sont semblables au cc-NUMA. Pour obtenir de bonnes performances, il est imp
erieux que l'acc
es aux
donn
ees soit local au processeur ex
ecutant le calcul. La non-uniformit
e dans l'acc
es a
la m
emoire est
plus marqu
ee avec les SDSM que dans les machines cc-NUMA. Ainsi, la localisation des donn
ees devrait
avoir un eet beaucoup plus prononc
e.
Nous avons employ
e le syst
eme SDSM TreadMarks. TreadMarks est bas
e sur le protocole de coh
erence
paresseux [12] et le protocole d'
ecrivains multiples pour r
eduire l'eet de faux partage.
Nous mettons en oeuvre pour chaque exemple deux versions, une partag
ee, une priv
ee. La m
emoire
est par d
efaut priv
ee dans TreadMarks et seule la m
emoire allou
ee explicitement a
l'aide d'appels a
la
biblioth
eque est partag
ee [16]. Pour la version partag
ee, l'ensemble du tableau est d
eclar
e partag
e.
La version priv
ee n'alloue qu'un buer n
ecessaire pour permettre la mise a
jour de la zone de recouvrement (ou shadow) (Jacobi en section 4.1 et LBE en section 4.2) ou la diusion de la colonne normalis
ee
(LU en section 4.3). Ainsi, tous les calculs emploient des donn
ees priv
ees. Ces codes SPMD avec TreadMarks sont tr
es proches des codes SPMD e
crit pour les versions priv
ees d'OpenMP sur l'Origin 2000.
Les exp
eriences ont e
t
e r
ealis
ees sur le SP2 d'IBM situ
ea
l'Universit
e de Houston. Ce syst
eme comporte
64 noeuds assembl
e en 5 parties dont 48 noeuds ns - des P2SC (Power2 Superchip) a
120MHz - avec une
m
emoire de 128 Mo. Toutes les exp
eriences ont e
t
e faites sur ces noeuds ns, dans un mode non-d
edi
e.
Tous les noeuds utilisent le syst
eme IBM AIX 4.3. Le compilateur C d'IBM C version 3.6.6 a e
t
e utilis
e
pour tous les programmes qui ont e
t
e li
es avec la version 1.0.3.3-BETA de la biblioth
eque TreadMarks. Les
options de compilation suivantes ont e
t
e utilis
ees : -O3 -qstrict -qarch=pwr2 -qtune=pwr2 .
4. Programmes utilises
Nous avons e
valu
e les performances de notre approche sur des noyaux typiques a
savoir Jacobi, la
factorisation LU et l'
equation de Boltzmann. Les acc
el
erations (speedups) sont entendus par rapport au
4
temps de la version s
equentielle pour chaque noyau.
4.1. Jacobi
Jacobi est une m
ethode courante pour r
esoudre des e
quations di e
rentielles partielles. L'algorithme de
Jacobi poss
ede une localit
e spatiale excellente (Programme 1 et Figure 2(a)). Tous les acc
es aux donn
ees
peuvent e
^ tre rendus locaux except
es pour les e
l
ements a
la fronti
ere acc
ed
es en lecture partag
ee. Ainsi,
c'est un exemple typique o
u des architectures NUMA peuvent obtenir une bonne performance puisque
l'acc
es partag
e est en lecture seule et de plus sur une faible portion des donn
ees.
(a)
(b)
(c)
Figure 2. Schemas des acces pour Jacobi (a), LBE (b) et LU (c)
!$OMP PARALLEL DO
do j = 1,n
do i = 1,n
A(i,j) = (B(i-1,j)+B(i+1,j)+B(i,j-1)+B(i,j+1)) * c
end do
end do
!$OMP END PARALLEL
Programme 1. Noyau du Jacobi
!$SGI DISTRIBUTE A(*,block), B(*,block)
!$OMP PARALLEL DO
do j = 1,n
do i = 1,n
A(i,j) = (B(i-1,j)+B(i+1,j)+B(i,j-1)+B(i,j+1)) * c
end do
end do
!$OMP END PARALLEL DO
Programme 2. Noyau du Jacobi avec DISTRIBUTE
Une distribution BLOCK dans la deuxi
eme dimension des deux tableaux A et B permet d'obtenir une bonne
localit
e et un bon e
quilibrage de charge. Dans la version priv
ee, nous avons employ
e une zone shadow
pour avoir acc
es aux e
l
ements situ
es a
la fronti
ere. Le partage des donn
ees le long de la fronti
ere est
r
ealis
e via 2 buers partag
es de la taille d'une colonne par processeur, a
part pour les processeurs 0 et
N-1 qui ont un seul buer partag
e. Ainsi le tableau eectivement partag
e utilis
e pour impl
ementer ces
buers est de taille (2*N-2) * taille d'une colonne, ou 'N' est le nombre de processeurs.
5
!$SGI DISTRIBUTE_RESHAPE A(*,block), B(*,block)
!$OMP PARALLEL DO
do j = 1,n
do i = 1,n
A(i,j) = (B(i-1,j)+B(i+1,j)+B(i,j-1)+B(i,j+1)) * c
end do
end do
!$OMP END PARALLEL DO
Programme 3. Noyau du Jacobi avec DISTRIBUTE RESHAPE
!$OMP PARALLEL SHARED(buflower,bufupper,chunk) &
!$OMP PRIVATE(A,B,thdno,noofthds,start_x,end_x,start_y,end_y,i,j,k)
.......
.......
do k = 1, ITER
bufupper(1:n,thdno) = A(1:n,chunk)
buflower(1:n,thdno) = B(1:n,1)
!$OMP BARRIER
B(1:n,0) = bufupper(1:n,thdno-1)
B(1:n,chunk+1) = buflower(1:n,thdno+1)
do j = start_y, end_y
do i = start_x, end_x
A(i, j) = (B(i-1, j) + B(i+1, j) + B(i, j-1) + B(i,j+1)) * c
enddo
enddo
do j = start_y, end_y
B(1:n, j) = A(1:n, j)
enddo
enddo
!$OMP END PARALLEL
Programme 4. Noyau du Jacobi en style SPMD
Nous pouvons voir dans la Fig. 3 le sch
ema des mouvements des donn
ees durant l'ex
ecution du Jacobi :
les threads copient d'abord leurs zones fronti
eres de facon a
acc
eder aux valeurs r
ecentes dans leur
zones shadow. Le reste du programme s'eectue alors uniquement sur des donn
ees locales.
Nous montrons tout d'abord les r
esultats obtenus avec la migration automatique des pages autoris
ee (Fig.
3). Nous observons que nous obtenons une acc
el
eration quasi lin
eaire avec moins de 8 threads, mais
apr
es, le rendement s'eondre car des pages sont migr
ees (et ce sur une distance d'autant plus grande
que le nombre de threads est e
lev
e, traversant parfois plus de 2 hubs), pr
esentant m^
eme certainement
des eets de ping-pong des pages associ
ees au fronti
ere des donn
ees distribu
ees. Ces migrations de
pages entra^nent une d
egradation des performances (si l'on compare aux versions sans migration en Fig.
4). Aussi, pour le reste des exp
erimentations, nous n'autoriserons pas de migration automatique.
Sur l'Origin 2000, comme un processeur lit essentiellement des donn
ees locales, a
l'exception d'une ligne
provenant des processeurs voisins, les rendements(speedups) observ
es sont lin
eaires (et m^
eme superlin
eaires) (Fig. 4(a)). Le \First Touch" et DISTRIBUTE montrent une ecacit
e comparable puisque, dans
cet exemple, la pagination est la m^
eme apr
es la phase d'initialisation. L'
ecart observ
e a
partir de 4
processeurs est d^
u justement a
cette initialisation o
u le syst
eme d'exploitation d
eplace les pages selon
la politique du \First Touch", tandis que dans la version DISTRIBUTE, ce placement est r
ealis
e lors de la
eger surco^
ut certainement
compilation. Le DISTRIBUTE RESHAPE est comparable au DISTRIBUTE avec un l
6
Jacobi Speedups with Page Migration on SGI
9
0
1
2
8
3
No Distribution
Distribute(*,Block)
7
Distribute_Resha−
pe(*,Block)
Speedup
6
5
4
3
2
1
0
Private Array
Shadow Rows
Shared Buffers
1
2
4
8
16
32
Number of Threads
Figure 3. Schema d'execution pour le Jacobi SPMD et acceleration avec Migration automatique des pages
d^
ua
l'arithm
etique des pointeurs utilis
ee pour acc
eder aux e
l
ements.
La version Privee montre des acc
el
erations super-lin
eaires (75 pour 64 processeurs), principalement en
raison de la privatisation des donn
ees qui impliquent un meilleur eet de cache (niveaux 1 et 2) et de la
moindre intrusion du syst
eme d'exploitation dans la gestion des variables partag
ees, puisqu'elles ne sont
uniquement employ
ees que pour mettre a
jour les zones shadow apr
es chaque it
eration du Jacobi, et
non pas durant les calculs. Ces mises a
jours sont donc vectoris
ees, d'o
u ces meilleures performances.
Avec plus de processeurs (jusqu'
a 128), nous observons toujours une grande ecacit
e, mais qui n'est plus
lin
eaire car il n'y a plus assez de calcul pour chaque processeur pour une matrice de taille 1024 × 1024 .
80
Jacobi sur IBM SP2/TreadMarks (1024x1024)
6
Jacobi Speedups on SGI 2000
5
70
Shared
No Distribute
Private
Distribute
60
Distribute Reshape
4
Speedup
Speedup
Private
50
40
30
3
2
20
1
10
0
0
1
2
4
8
16
1
32
Number of Threads
2
4
8
Nb de Processeurs
16
32
(a)
(b)
Figure 4. Acceleration du Jacobi sur SGI O2000 (a) et IBM SP2 (b) (1024 × 1024 en double precision)
Avec TreadMarks sur IBM SP2, les performances pour la version avec un tableau partag
e sont tr
es
faibles et ce d
es 2 processeurs (Fig. 4(b)). En fait, nous remarquons un fort ralentissement avec plus de 8
processeurs. Pour le cas priv
e, nous obtenons une acc
el
eration quasi lin
eaire jusqu'
a 16 processeurs. Avec
32 processeurs, la courbe s'aaisse. Le faible rendement pour la version partag
ee est attribu
e au co^
ut
e
lev
e induit par le maintient de la coh
erence sur un grand nombre de pages partag
ees, contrairement a
la version priv
ee qui poss
ede un nombre plus faible de pages partag
ees (seulement un buer).
4.2. Equation
de Boltzmann
LBE est un code de dynamique des uides qui r
esout l'
equation de Boltzmann (Lattice Boltzmann Equation,
LBE [9]). L'algorithme est semblable a
Jacobi avec un sch
ema d'acc
es en e
toile except
e que les e
l
ements
voisins sont mis a
jour et non pas lus (Fig. 2(b)). Ainsi c'est un cas d'acc
es partag
e en e
criture plut^
ot qu'en
lecture, soit un fort potentiel de prendre en d
efaut le fonctionnement de la m
emoire partag
ee. En eet,
7
il est possible d'avoir de multiples lectures sur la m^
eme ligne de cache (ou page), mais pas de multiples
e
critures. C'est donc un bon exemple pour analyser une faiblesse des architectures NUMA.
!$OMP PARALLEL
do iter = 1, niters
Calculate_ux_uy_p
Collision_advection_interior
Collision_advection_boundary
end do
!$OMP END PARALLEL
Collision_advection_interior:
!$OMP DO
do j = 2, Ygrid-1
do i = 2, Xgrid-1
f(i,0,j)
= Fn(fold(i,0,j))
f(i+1,1,j) = Fn(fold(i,1,j))
f(i,2,j+1) = Fn(fold(i,2,j))
f(i-1,3,j) = Fn(fold(i,3,j))
.....
f(i+1,8,j-1) = Fn(fold(i,8,j)
end do
end do
!$OMP END DO
Programme 5. Algorithme LBE et noyau de Collision advection interior
!$SGI DISTRIBUTE ux(*,BLOCK),uy(*,BLOCK),p(*,BLOCK),f(*,*,BLOCK),fold(*,*,BLOCK)
!$OMP PARALLEL
do iter = 1, niters
Calculate_ux_uy_p
Collision_advection_interior
Collision_advection_boundary
end do
!$OMP END PARALLEL
Programme 6. Noyau de LBE avec DISTRIBUTE
!$SGI DISTRIBUTE_RESHAPE ux(*,BLOCK),uy(*,BLOCK),p(*,BLOCK),f(*,*,BLOCK),fold(*,*,BLOCK)
!$OMP PARALLEL
do iter = 1, niters
Calculate_ux_uy_p
Collision_advection_interior
Collision_advection_boundary
end do
!$OMP END PARALLEL
Programme 7. Noyau de LBE avec DISTRIBUTE RESHAPE
Collision advection interior (Prog. 2) est le seul sous-programme de LBE qui poss
ede un acc
es
partag
e aux donn
ees. Les matrices sont distribu
ees par BLOCK dans la derni
ere dimension pour assurer
de nouveau une bonne localit
e et un bon e
quilibrage de charge. Dans la version priv
ee, nous avons
employ
e une zone shadow pour avoir acc
es aux e
l
ements voisins et un buer partag
e de la taille de ces
fronti
eres (comme dans Jacobi) pour la mise a
jour distante.
Sur l'Origin 2000, nous pouvons voir cette fois que toutes les versions employant l'extension SGI d'OpenMP
ou le \First Touch" ont des r
esultats quasi identiques, avec un l
eger avantage pour DISTRIBUTE RESHAPE
(Fig. 5(a)). Cette fois, les rendements sont sous-lin
eaires, car chaque processeur doit acc
eder a
la m
emoire
du voisin en e
criture, contrairement a
Jacobi. Ce partage en e
criture prend en d
efaut le support du syst
eme
d'exploitation pour la m
emoire partag
ee, avec un eet de ping-pong des lignes de cache associ
ees.
L'architecture cc-NUMA peut e
galement e
^ tre rendue responsable, car, pour 16 ou 32 processeurs, l'acc
es
a
une donn
ee non-locale peut se faire en traversant 2 noeuds, obtenant donc de plus long temps d'acc
es.
La version Privee de LBE montre une am
elioration notable de l'acc
el
eration pour 16 et 32 processeurs.
D'une part, il y a une augmentation de la localit
e des donn
ees (eet de cache) et d'autre part la synchronisation est faite seulement a
la n de chaque it
eration. Tous les processeurs font donc leur calcul
8
LBE sur SGI Origin 2000 (256x256)
35
LBE sur IBM SP2/TreadMarks (256x256)
4.5
33
No Distribution
30
3.5
Hand
Translated(*,Block)
Speedup
23
Shared
Private
Distribute_Resha−
pe(*,Block)
25
Speedup
4
Distribute(*,Block)
28
20
18
15
3
2.5
13
10
2
8
5
1.5
3
0
1
2
4
8
16
1
32
1
2
Nb de Threads OpenMP
4
8
16
32
Nb de Processeurs
(a)
Figure 5. Acceleration de LBE sur SGI O2000 (a) et IBM SP2 (b) (256 × 256)
(b)
seulement sur des donn
ees priv
ees jusqu'
a la n de l'it
eration (vectorisation des messages).
Avec TreadMarks sur IBM SP2, nous observons une moindre am
elioration de la version priv
ee compar
ee a
la version partag
ee (Fig. 5(b)). Les deux versions ont des acc
el
erations raisonnables (3.5 sur 16 processeurs
pour la version partag
ee, 4.5 pour la version priv
ee) puisque la quantit
e de m
emoire partag
ee n'est pas
trop importante, d'o
u un co^
ut faible pour le maintien de la coh
erence sur les processeurs. N
eanmoins
la privatisation permet d'obtenir une meilleure ecacit
e puisque le nombre de pages maintenues y est
moindre que dans la version partag
ee (seuls les buers sont partag
es). Avec plus de 16 processeurs, les
ecacit
es diminuent en raison d'un manque de calculs par rapport aux communications requises.
4.3. Factorisation LU
La factorisation LU (Progr. 8) est souvent employ
ee comme une partie d'une r
esolution de syst
eme. Elle
factorise la matrice en deux sous matrices, triangulaires sup
erieure et inf e
rieure.
!$OMP PARALLEL
do k = 1,n-1
!$OMP SINGLE
lu(k+1:n,k) = lu(k+1:n,k)/lu(k,k)
!$OMP END SINGLE
!$OMP DO
do j = k+1, n
lu(k+1:n,j) = lu(k+1:n,j) - lu(k,j) * lu(k+1:n,k)
end do
!$OMP END DO
end do
!$OMP END PARALLEL
Programme 8. Factorisation LU
Semblable a
Jacobi, il n'y a que des acc
es partag
es en lecture et seule la colonne courante normalis
ee
est concern
ee (Fig. 2(c)). Mais pour e
^ tre ecace, tous les threads doivent participer a
la mise a
jour
presque jusqu'
a la n. D'ou, pour un bon e
quilibrage de charge, une distribution CYCLIC sur la deuxi
eme
dimension est n
ecessaire. C'est un bon exemple o
u la norme OpenMP n'a aucune r
eponse pour un
besoin si sp
ecique et montre donc un int
er^
et fort de la capacit
ea
sp
ecier la distribution des donn
ees
et donc la distribution des calculs associ
es. Dans la version priv
ee, nous employons seulement un tableau
partag
e de la taille d'une colonne an de rendre accessible la colonne normalis
ee a
tous les processeurs.
Sur l'Origin 2000, toutes les versions, apr
es 16 processeurs (Fig. 7(a)), ont un rendement sous-lin
eaire en
raison, principalement, du manque de travail sur chaque processeur (ratio calculs/communications e
lev
e).
Si nous consid
erons la version OpenMP sans distribution, son mauvais rendement est d^
ua
une mauvaise
9
!$SGI DISTRIBUTE lu(*,CYCLIC)
!$OMP PARALLEL
do k = 1,n-1
!$OMP SINGLE
lu(k+1:n,k) = lu(k+1:n,k)/lu(k,k)
!$OMP END SINGLE
!$OMP DO
do j = k+1, n
lu(k+1:n,j) = lu(k+1:n,j) - lu(k,j) * lu(k+1:n,k)
end do
!$OMP END DO
end do
!$OMP END PARALLEL
Programme 9. LU avec DISTRIBUTE
!$SGI DISTRIBUTE_RESHAPE lu(*,CYCLIC)
!$OMP PARALLEL
do k = 1,n-1
!$OMP SINGLE
lu(k+1:n,k) = lu(k+1:n,k)/lu(k,k)
!$OMP END SINGLE
!$OMP DO
do j = k+1, n
lu(k+1:n,j) = lu(k+1:n,j) - lu(k,j) * lu(k+1:n,k)
end do
!$OMP END DO
end do
!$OMP END PARALLEL
Programme 10. LU avec DISTRIBUTE RESHAPE
r
epartition sur les 32 processeurs. En eet, par d
efaut, la r
epartition initiale (r
esultant du \First Touch")
ressemblera a
une distribution BLOCK qui n'est pas appropri
ee pour pour l'
equilibrage de charge avec
LU. Les versions DISTRIBUTE et DISTRIBUTE RESHAPE sont donc meilleures car la distribution re
ete le
besoin pour l'
equilibrage de charge.
Dans la version Privee, la seule partie pr
esentant une synchronisation entre les processeurs est lorsque
chaque processeur recopie "la colonne normalis
ee partag
ee" dans son buer priv
e. Le reste du calcul est
alors parfaitement parall
ele o
u chaque processeur fait ses calculs sur ses propres donn
ees sans aucune
donn
ee partag
ee. Le rendement super-lin
eaire vient de nouveau de la privatisation des donn
ees, visant
a
la fois a
un meilleur eet de cache et a
une vectorisation des mises a
jour des buers partag
es.
Avec TreadMarks sur IBM SP2, pour la version partag
ee, nous remarquons de faibles acc
el
erations jusqu'
a
16 processeurs maximum (Fig. 7(b)), sup
erieures a
celles obtenues avec Jacobi, principalement en raison
du fait que, dans LU, seule une colonne par it
eration est acc
ed
ee de mani
ere partag
ee. De l
a, le nombre
de pages a
mettre a
jour est moindre que dans Jacobi (2*N - 2 lignes par it
eration).
Pour la version Privee, nous remarquons des acc
el
erations quasi lin
eaires jusqu'
a 8 processeurs. Au-del
a,
la baisse de rendement peut e
^ tre attribu
ee a
la facon dont, dans LU, comme l'ex
ecution progresse, la
quantit
e de calcul a
r
ealiser par it
eration diminue. Cet eet est d'autant plus marqu
e que le nombre de
processeurs est grand, d'ou le surco^
ut d^
ua
la synchronisation prend le pas sur les calculs.
4.4. Resume des experimentations sur les deux plate-formes
Sur l'Origin 2000 de SGI, nous avons observ
e que prendre soin de la distribution des donn
ees (et des
calculs selon les donn
ees) peut radicalement augmenter l'ecacit
e des applications, et ce, m^
eme si l'on
admet que la machine poss
ede un syst
eme de m
emoire partag
ee ecace. L'architecture cc-NUMA est
responsable de ce r
esultat. Nous observons par exemple que le \First Touch" n'est pas toujours susant
pour obtenir une bonne ecacit
e, comme avec l'application LU.
Nous observons aussi que la privatisation des tableaux (en les placant explicitement sur la m
emoire
locale de chaque processeur) permet de meilleurs rendements, voire m^
eme super-lin
eaire. Ceci est
10
K
0
1
3
2
Private Array
Shared Buffer
Private Buffer
Figure 6. Schema d'execution du LU SPMD
LU Speedups on SGI Origin 2000
70
LU sur IBM SP2/TreadMarks (2048x2048)
5.0
4.5
60
Distribute(*,cyclic)
4.0
Distribute_Resha−
pe(*,cyclic)
3.5
Speedup
50
Speedup
Shared
No Distribution
Hand
Translated(*,cyclic)
40
30
Private
3.0
2.5
20
2.0
10
1.5
1.0
0
1
2
4
8
16
32
1
2
Number of Threads
4
8
16
32
Nb de Processeurs
(a)
Figure 7. Acceleration pour LU sur SGI O2000 (a) et IBM SP2 (b) (2048 × 2048)
(b)
principalement d^
ua
deux facteurs. D'abord, la privatisation place les donn
ees dans la m
emoire locale du
noeud dans le syst
eme SGI, donc elles sont plus proches du processeur et permettent de b
en
ecier des
eets de caches des niveaux 1 et 2, souvent responsables d'acc
el
eration super-lin
eaire. Deuxi
emement,
cette privatisation implique un style de programmation qui a tendance a
placer toutes les communications
a
l'ext
erieur des calculs, soit un processus de vectorisation des communications. Ce second eet, bien
connu dans la recherche concernant HPF [8] est aussi responsable des meilleures performances.
Avec la biblioth
eque SDSM TreadMarks, le nombre total des pages maintenues pour les versions partag
ees est beaucoup plus grand que pour les versions priv
ees. Par cons
equent, le surco^
ut impliqu
e par le
maintient de la coh
erence de la m
emoire partag
ee pour une version partag
ee est beaucoup plus grand
que pour une version priv
ee. De plus, pour cette derni
ere, comme le nombre de pages partag
ees est
faible, le co^ut de marquage dans le syst
eme TreadMarks est lui aussi plus bas [7]. Ce faible co^
ut est re
et
e
par les am
eliorations de rendement observ
ees. En eet, la quantit
e d'informations e
chang
ees pour la
coh
erence aecte aussi le temps pass
e dans les barri
eres et synchronisations, principalement en raison
de la version centralis
ee du syst
eme impl
ement
e dans TreadMarks.
Pour r
ecapituler, nous observons dans les deux architectures NUMA, que ce soit cc-NUMA ou bas
ee sur
un SDSM, que la localit
e de donn
ees est un facteur important pour obtenir une bonne ecacit
e. Et nous
voyons que la privatisation est une facon d'obtenir ce r
esultat. Cependant, l'
ecriture de tels codes est
dicile d'o
u notre proposition d'
etendre le langage an de les obtenir directement par compilation.
5. Travaux relatifs
OpenMP[3] est constitu
e de directives permettant de d
ecrire le parall
elisme de mani
ere simple. Ces
directives ont e
t
e concues pour l'ex
ecution de programmes sur des machines parall
eles a
m
emoire
11
!$OMP PARALLEL SHARED(shbuf)&
!$OMP PRIVATE(lu,sumP,counter,noofthds,id,i,j,K,pribuf,Npri)
DO K=1,N-1
! Compute Column K
if(mod(K-1,noofthds).eq.id) then
lu(K+1:N,counter) = lu(K+1:N,counter) / lu(K,counter)
!move the column K to the sharedbuffer
shbuf(K+1:N) = lu(K+1:N,counter)
counter = counter+1
end if
!$OMP BARRIER
!move the sharedbuffer to private buffer or column 0
pribuf(K+1:N) = shbuf(K+1:N)
! Update Right Part (Column J+1:N)
do j = counter, Npri
lu(K+1:N, j) = lu(K+1:N, j) - lu(K, j) * pribuf(K+1:N)
end do
END DO
!$OMP END PARALLEL
Programme 11. Noyau LU en style SPMD
partag
ee et reposent essentiellement sur la notion de boucles parall
eles et de variables partag
ees ou
priv
ees. Au contraire d'HPF[8], OpenMP ne propose aucune directive permettant d'orienter la distribution
des donn
ees car OpenMP consid
ere un acc
es uniforme de tous les processeurs a
la m
emoire partag
ee.
De nombreuses e
tudes ont d
ej
a port
e sur l'extension d'OpenMP a
des architectures a
acc
es non uniforme
a
la m
emoire. Certains ont consid
er
e des mod
eles de programmation mixtes pour les grappes de noeuds
SMP, utilisant a
la fois MPI et OpenMP pour parall
eliser les applications [20, 4]. Il est g
en
eralement admis que
l'ecacit
e de cette approche d
epend fortement des propri
et
es sous-jacentes de l'application e
tudi
ee.
N
eanmoins, il appara^t e
galement que ce style de programmation n'est pas ais
e pour le programeur
puisqu'il doit faire face a
la programmation SMPD qu'impose MPI [6].
Nous pensons qu'il est possible avec un minimum d'extensions a
OpenMP d'obtenir un langage a
base
de directives qui facilite la programmation et permette d'obtenir de bonnes performances sur de telles
architectures. Il existe d
ej
a quelques impl
ementations de compilateurs OpenMP d
edi
es pour des grappes
de noeuds SMP comme le compilateur Omni OpenMP [18, 17], mais ce dernier n'inclue pas de directives
de placement des donn
ees et repose essentiellement sur un SDSM pour impl
ementer la m
emoire partag
ee
le long des noeuds.
Dans [15], les auteurs avancent que leurs exp
erimentations, incluant jusqu'
a 16 processeurs, montrent qu'il
n'est pas besoin de distribuer les donn
ees avec OpenMP, puisque la migration des pages a
l'ex
ecution
donne souvent les meilleures performances. N
eanmoins, leurs exp
erimentations montrent que de tenir
compte d
es le d
ebut du bon placement des donn
ees (en utilisant le First Touch) donne syst
ematiquement les
meilleurs r
esultats. Nous pensons, premi
erement, que ces performances devraient s'am
eliorer en utilisant
les directives de distribution DISTRIBUTE du compilateur OpenMP de SGI. Deuxi
emement, nous pensons
e
galement que ces eets devraient e
^ tre plus frappant en utilisant plus de 16 processeurs, de facon a
augmenter la latence m
emoire moyenne, sp
ecialement dans le cas d'un \false-sharing" qui introduit des
eects de ping-pong sur les pages en causes.
Comme nous l'avons d
ej
a pr
esent
e dans cet article, SGI a consid
er
e le placement des donn
ees et des
calculs comme e
tant dans certains cas un point crucial pour obtenir de bonnes performances sur des
syst
emes cc-NUMA comme l'Origin 2000 [10] an de r
eduire les e
carts entre les temps d'acc
es a
la m
emoire
distante et locale [19]. Nos exp
erimentations montrent que l'impl
ementation choisie par SGI pourrait sans
doute b
en
ecier de quelques am
eliorations, notamment par la prise en compte de la directive SHADOW.
Compaq, pour ses AlphaServers de type cc-NUMA, a e
galement introduit des extensions inspir
ees directe12
for(ck=0,k=Tmk_proc_id; ck < N-1 ;ck++)
{
if(ck == k)
{
for(j=ck+1;j<N;j++)
shared->lu[j] = lu[ck/Tmk_nprocs][j] =
lu[ck/Tmk_nprocs][j] / lu[ck/Tmk_nprocs][ck];
k = k + Tmk_nprocs;
}
Tmk_barrier(1);
/* update right part. */
for(j=k;j<N;j+=Tmk_nprocs)
for(i=ck+1;i<N;i++)
lu[j/Tmk_nprocs][i] = lu[j/Tmk_nprocs][i] lu[j/Tmk_nprocs][ck]*shared->lu[i];
Tmk_barrier(2);
}
Programme 12. Factorisation LU avec TreadMarks
ment de HPF dans leur compilateur OpenMP [2]. Ces extensions couvrent un plus large spectre que celles
de SGI, bien que tr
es semblables - notamment pour ce qui est d'une distribution bas
ee sur la pagination
et une autre bas
ee sur les e
l
ements eux-m^
emes -, en introduisant e
galement les alignements entre les
donn
ees et la possibilit
e de restreindre la distribution a
un sous-ensemble de processeurs.
L'inconv
enient de l'approche de Compaq est de proposer un langage sans doute trop riche pour pouvoir
e
^ tre facilement port
e sur d'autres types d'architectures, et pose donc le probl
eme de la portabilit
e des
codes e
crits pour les architectures Compaq vers d'autres architectures.
Enn, Portland Group Inc. (PGI) propose e
galement des extensions au langage OpenMP dans un langage
nomm
e Distributed OpenMP (DoMP) [14, 11]. Ces extensions concernent principalement les grappes de
noeuds a
m
emoire partag
ee, incluant aussi les cc-NUMA et les architectures a
m
emoire distribu
ee. Ils
proposent e
galement les directives DISTRIBUTE et ON HOME pour distribuer les donn
ees et les calculs,
mais cette fois ci sur les m
emoires des noeuds et non des processeurs de facon a
re
eter la structure de
la m
emoire sur les grappes de noeuds.
Cette approche, di e
rente des deux premi
eres, utilise comme mod
ele d'ex
ecution celui de HPF en
dehors de toute r
egion PARALLEL, et a
l'int
erieur d'une r
egion PARALLEL, celui d'un OpenMP distribu
e.
Pour simplier, un thread OpenMP distribu
e est en fait constitu
e de plusieurs threads r
epartis sur les
noeuds, communiquant entre eux pour assurer les acc
es aux m
emoires distantes.
6. Conclusion
Toutes ces approches proposent diverses extensions et interpr
etations an de prendre en compte l'aspect
distribu
e de la m
emoire. Toutes ces approches sont attractives mais emp^
echent l'utilisateur de r
ealiser
une version portable de son code puisque chacune d'entre elles constituent des extensions propri
etaires.
Notre but est donc de d
enir un ensemble minimum d'extensions qui seront vraiment utiles et aussi
portables que possible.
Nous montrons dans cet article qu'un premier sous-ensemble de directives serait constitu
e des directives
de distribution des donn
ees (DISTRIBUTE) et des calculs en fonction des donn
ees (ON HOME), mais aussi de
la directive SHADOW permettant de consid
erer les donn
ees acc
ed
ees a
la fronti
ere de ces zones distribu
ees.
Les exp
erimentations ont montr
e que les performances e
taient nettement am
elior
ees en utilisant une
privatisation des donn
ees, et ce aussi bien pour des architectures cc-NUMA tel le Origin 2000 de SGI
que des architectures a
m
emoire partag
ee r
epartie logicielle comme l'IBM SP2 avec la biblioth
eque de
support pour une m
emoire partag
ee TreadMarks.
D'autres e
tudes sont encore n
ecessaires, et notamment pour mieux prendre en compte les architectures
du type grappes de noeuds a
m
emoire partag
ee, en raison de l'
ecart important entre le temps d'acc
es aux
donn
ees locales et aux donn
ees distantes via le r
eseau. Les techniques utilis
ees devront certainement
13
h
eriter des e
tudes pass
ees portant sur HPF, et notamment sur les capacit
es a
analyser et optimiser les
communications entre les noeuds. M^
eme si le compilateur s'appuie sur un support SDSM pour impl
ementer
le partage de la m
emoire sur l'ensemble des noeuds, il demeure selon nous important de conserver la
notion de localit
e des donn
ees de facon a
limiter le surco^
ut induit par ce support.
Bibliographie
1. C. Amza, A. Cox, et et al. Treadmarks : Shared memory computing on networks of workstations. IEEE
Computer, 29(2) :18{28, F
evrier 1996.
2. J. Bircsak, P. Craig, R. Crowel, J. Harris, C.A. Nelson, et C.D. Oner. Extending OpenMP For NUMA
Machines : The Language. Dans WOMPAT 2000, Workshop on OpenMP Applications and Tools, San Diego
Supercomputer Center, San Diego, California, Juillet 2000.
3. OpenMP Architecture Review Board. OpenMP Fortran Application Program Interface, Version 2.0,
Novembre 2000.
4. F. Cappello et D. Etiemble. MPI versus MPI+OpenMP on IBM SP for the NAS Benchmarks. Dans SC2000,
Supercomputing, Dallas, Texas, USA, Novembre 2000.
5. R. Chandra, D.K. Chen, R. Cox, D.E. Maydan, N. Nedeljkovic, et J.M. Anderso. Data Distribution
Support on Distributed Shared Memory Multiprocessors. Dans Conference on Programming Language
Design and Implementation, 1997.
6. B. Chapman, J. Merlin, D. Pritchard, F. Bodin, Y. Mevel, T. Sorevik, et L. Hill. Tools for Development of
Programs for a Cluster of Shared Memory Multiprocessors. Dans PDPTA'99, Las Vegas, USA, 1999.
7. E. de Lara, Y.C. Hu, H. Lu, A.L. Cox, et W. Zwaenepoel. The Eect of Memory Contention on
the Scalability of Page-based Software Distributed Shared Memory Systems. Dans Proceedings of
Languages, Compilers, and Runtimes for Scalable Computing, Mai 2000.
8. HPF Forum. High Performance Fortran language specication, Version 2.0, Janvier 1997.
9. X. He et L. Luo. Theory of the lattice Boltzmann method : From the Boltzmann equation to the lattice
Boltzmann equation. Phys. Rev. Lett. E,56(6) 6811, 1997.
10. Silicon Graphics Inc. MIPSPro Fortran 90 Commands and Directives Reference Manual. Document
number 007-3696-003. Search keyword MIPSPro Fortran 90 on http ://techpubs.sgi.com/library/.
11. J. Merlin (The Portland Group, Inc.). Distributed OpenMP : Extensions to OpenMP for SMP Clusters.
Dans EWOMP 2000, European Workshop on OpenMP, Edimburgh, Scotland, U.K., Septembre 2000.
12. P. Keleher, A. Cox, et W. Zwaenepoel. Lazy release consistency for software distributed shared
memory. Dans 19th Annual International Symposium on Computer Architecture, pages 12{21, Mai 1992.
13. P. Keleher, S. Dwarkadas, A. Cox, et W. Zwaenepoel. Treadmarks : Distributed shared memory on
standard workstations and operating systems. Dans Winter Usenix Conference, pages 115{131, Janvier
1994.
14. M. Leair, J. Merlin, S. Nakamoto, V. Schuster, et M. Wolfe. Distributed OMP - A Programming Model
For SMP Clusters. Dans CPC2000, Compilers for Parallel Computers, Aussois, France, Janvier 2000.
15. D.S. Nikolopoulos, T.S. Papatheodorou, C.D. Polychronopoulos, J. Labarta, et E. Ayguad
e. Is Data
Distribution Necessary in OpenMP ? Dans SC2000, Supercomputing, Dallas, Texas, USA, Novembre
2000.
16. Concurrent
Programming
with
TreadMarks.
TreadMarks
users
Manual.
http ://www.cs.rice.edu/ willy/papers/doc.ps.gz.
17. M. Sato, H. Harada, et Y. Ishikawa. OpenMP compiler for a Software Distributed Shared Memory
System SCASH. Dans WOMPAT 2000, San Diego, Juillet 2000.
18. M. Sato, S. Satoh, K. Kusano, et Y. Tanaka. Design of OpenMP Compiler for an SMP Cluster. Dans
EWOMP'99, European Workshop on OpenMP, pages 32{39, Lund, Sweden, Septembre 1999.
19. S. Seidel. Access Delays Related to the Main Memory Heirarchy on the SGI Origin2000. Dans Third
European CRAY-SGI Workshop, Paris, France, Septembre 1997.
20. L.A. Smith et J.M. Bull. Development of Mixed Mode MPI/OpenMP Applications. Dans WOMPAT 2000,
San Diego, Juillet 2000.
14