Chapitre II : Les simulations de dynamique
III.2 L’impl´ementation GPU
III.3.3 La consommation m´emoire
La consommation m´emoire est la limite de notre simulation de SRD-MD nous
empˆechant de pouvoir simuler des syst`emes `a plus grande ´echelle, `a cause du nombre tr`es
important de particules de fluide `a mod´eliser compar´e au nombre de collo¨ıdes. Pour une
simulation avec une fraction volumique de ΦC = 0.1, le nombre de particules de fluide est
1578 fois plus grand que le nombre de collo¨ıdes. Toutes les donn´ees de la simulation doivent
ˆetre stock´ees dans la m´emoire globale du GPU, afin d’´eviter les transferts m´emoires entre
CPU et GPU tr`es coˆuteux. Or la capacit´e m´emoire des GPUs est bien importante que celle
d’un CPU : la Tesla K20m poss`ede 5 Go de m´emoire et la carte GTX 690 2Go uniquement.
Cependant, les deux GPU de derni`eres g´en´erations dont nous avons pu avoir acc`es, avec
une capacit´e m´emoire bien plus importante de 12 Go, montre que cette limite par rapport
au CPU tend `a diminuer. De plus, une partie de cette m´emoire est d´ej`a utilis´ee par le
syst`eme de base, pour l’affichage, donc cette limite ne peut pas ˆetre atteinte.
Chaque particule requiert de stocker sa position, sa position tri´ee, sa v´elocit´e,
son acc´el´eration, son acc´el´eration pr´ec´edente, son d´eplacement depuis la derni`ere
r´eactualisation de la liste de Verlet et des cl´es de hachage pour l’associer aux cellules
des diff´erentes grilles. Chaque particule de fluide requiert ´egalement une cl´e de hachage
associ´ee `a sa cellule de SRD et un buffer m´emoire temporaire utilis´e pour des
Chapitre 3 : Simulations de SRD-MD
calculs d’analyse tel que le calcul de la temp´erature du syst`eme. Chaque collo¨ıde
requiert ´egalement deux listes de Verlet de respectivement nbM axN eighborCC et
nbM axN eighborCF ´el´ements, pour les interactions collo¨ıde-collo¨ıde et collo¨ıde-fluide.
Chaque cellule n´ecessite deux index des premi`eres et derni`eres particules qu’elle contient.
Chaque cellule de SRD n´ecessite un compteur des particules pr´esentes dans la cellule et la
vitesse du centre de masse ainsi qu’un axe al´eatoire de rotation. Dans le but de diminuer
la consommation, nous avons utilis´e le mˆeme espace m´emoire pour stocker tous les buffers
temporaires tels que les acc´el´erations ou les positions non tri´ees. Enfin, chaque g´en´erateur
al´eatoire a besoin de m´emoire pour stocker son ´etat.
La double pr´ecision est pr´ef´er´ee pour stocker les donn´ees flottantes pour une question
de validit´e des simulations. Dans un premier temps, les donn´ees avec trois coordonn´ees
(position, v´elocit´e, acc´el´eration, etc.) ont d’abord ´et´e stock´ees dans une structurevector4,
dans une organisation m´emoire nomm´ee Array of Structure (AoS), comme dans les
chapitres pr´ec´edents. Cette organisation m´emoire a pour avantage de diminuer le nombre
de transactions lors d’acc`es `a la m´emoire du GPU. Les r´esultats pr´esent´es dans le
tableau III.5 sont issu d’une impl´ementation utilisant cette organisation de cette m´emoire.
Afin de r´eduire au maximum la consommation m´emoire, nous avons r´eimpl´ement´e notre
simulation, en s´eparant dans 3 buffers diff´erents les coordonn´ees x, y et z, ce qui est appel´e
une organisation en Array of Structure (SoA). Il s’est r´ev´el´e qu’en plus de r´eduire la
consommation m´emoire, cette organisation m´emoire permet d’am´eliorer les performances
comme le montre le Tableau III.6, cette am´elioration des performances ´etant importante
pour les architectures les plus anciennes (30% plus rapide pour la GTX690 et 15% plus
rapide pour la K20m), tout en permettant de pouvoir simuler de plus grand syst`eme.
Cette organisation m´emoire peut ˆetre utilis´e pour tous les autres simulations pr´esent´ees
jusqu’`a pr´esent et permettre d’obtenir une am´elioration des performances du mˆeme ordre.
La diff´erence de performance entre une organisation SoA et AoS a ´et´e ´etudi´e dans [50], qui
indique que l’organisation en SoA favorise l’acc`es coalescent aux donn´ees, tandis que celle
en AoS permet de r´eduire le nombre de transactions, les threads chargeant les donn´ees par
paquet de 128 bit. Dans le cas de calcul sur des donn´ees organis´es de fa¸con coalescente,
comme c’est le cas dans les simulations de fluide, une organisation SoA est optimale.
Le Tableau III.7 r´esume la consommation m´emoire d’une notre simulation , avec une
organisation m´emoire en SoA. Il liste uniquement la m´emoire utilis´ee par les principaux
buffers en fonction du nombre de collo¨ıdes, de particules de fluide, de cellules de grille
r´eguli`ere et de SRD, sans prendre en compte la m´emoire utilis´ee pour les tests. Par
exemple, pour une simulation avec la fraction volumique collo¨ıdale de ΦC = 0.10,
#colloides = 10 500, #f luids = 16 658 282, #cell
grid= 15625, #cell
SRD= 2299968,
nbM axN eighborCC = 50 and nbM axN eighborCF = 24050, la m´emoire totale utilis´ee
outre celle concernant l’analyse est : 132o∗16 658 282 + 148o∗10 500 + 8o∗15625 + 28o∗
Chapitre 3 : Simulations de SRD-MD
Collo¨ıdes Fluide Temps/it´eration (ms) Total time (h)
GTX690 K20m GTX690 K20m
500 788 981 59 57 0.9 0.9
2 000 3 120 942 242 235 3.7 3.6
4 000 6 311 854 493 474 7.5 7.2
6 000 9 487 161 XXX 792 XXX 12.1
8 000 12 623 708 XXX 971 XXX 14.8
10 500 16 658 282 XXX 1 179 XXX 18.0
11 000 17 317 669 XXX XXX XXX XXX
Tableau III.6 – Temps moyen d’une it´eration et temps total d’une simulation de SRD-MD
pour ΦC = 0.1 durant 55000 it´erations, avec une organisation m´emoire en SoA, sur un
GPU GTX690, K20m et GTX970. Une it´eration est compos´ee de 8 ´etapes de MD et 1
´etape de SRD. “XXX” signifie que la consommation m´emoire de la simulation est trop
importante pour pouvoir ˆetre ex´ecut´ee sur le GPU.
2299968 + 4o∗10 500∗24100 = 3.28Go.
III.4 Conclusion
Dans ce chapitre, nous avons pr´esent´e un nouvel algorithme pour des simulations de
SRD-MD avec force de couplage sur GPU. Cet algorithme combine des pr´ec´edents travaux
sur la SRD et sur la MD sur GPU et propose un nouveau sch´ema de d´ecomposition afin
de s’adapter `a la sp´ecificit´e de la partie MD du mod`ele qui est li´ee `a notre force de
couplage. Ce nouveau sch´ema associe `a chaque bloc de threads un collo¨ıde et toutes ses
interactions `a calculer. Par rapport `a la d´ecomposition standard associant un thread par
collo¨ıde, cette strat´egie permet d’´eviter les divergences des warps li´ees aux probl`emes de
branches divergentes. En effet, dans la m´ethode standard, les threads doivent attendre
que tous les threads de leur warp ont termin´e de calculer leur interaction pour passer aux
collo¨ıdes suivants. Or plus la variation du nombre de voisins est importante entre collo¨ıdes,
plus le temps d’attente est important. Pour les syst`emes ayant un grand nombre de
particules voisines, notre sch´ema de d´ecomposition par bloc devient ainsi plus avantageux.
Cependant un bloc ´etant compos´e d’au minimum 32 threads, notre strat´egie n’est pas
adapt´ee pour les syst`emes ayant en moyenne moins de 32 voisins et en pratique, moins de
64, car nos r´esultats montrent que cette m´ethode est optimale avec des blocs de 2 warps.
Ainsi, dans le cas de nos simulations de SRD-MD avec force de couplage, la d´ecomposition
par bloc permet une acc´el´eration de 45% par rapport aux m´ethodes standards de la
litt´erature.
La limite de nos simulations est la consommation m´emoire tr`es importante due au
nombre tr`es ´elev´e de particules de fluide `a repr´esenter dans la SRD. Afin de r´eduire
Chapitre 3 : Simulations de SRD-MD
´el´ement consommation m´emoire
fluide sorted position = 24 o * #f luids
velocity = 24 o * #f luids
previous acceleration = 24 o * #f luids
displacement = 24 o * #f luids
temporary buffer (for unsorted position, acceleration,
center of mass velocity) = 24 o * #f luids
hash grid = 4 o * #f luids
hash SRD = 4 o * #f luids
total = 132 o * #f luids + 4 o * #f luids * nbM axN eighbor
collo¨ıdes position = 24 o * #colloids
sorted position = 24 o * #colloids
velocity = 24 o * #colloids
acceleration = 24 o * #colloids
previous acceleration = 24 o * #colloids
displacement = 24 o * #colloids
hash grid = 4 o * #colloids
verletCC = 4 o * #colloids * nbM axN eighborCC
verletCF = 4 o * #colloids *nbM axN eighborCF
total = 148 o * #colloids +
4 o * #colloids * (nbM axN eighborCC+nbM axN eighborCF)
grille index start = 4 o * #cell
gridr´eguli`ere index end = 4 o * #cell
gridtotal = 8 o * #cell
gridgrille SRD counter = 4 o * #cell
SRDrotation axis = 24 o * #cell
SRDtotal = 28 o * #cell
SRDChapitre 3 : Simulations de SRD-MD
la consommation m´emoire, nous avons changer l’organisation m´emoire en AoS avec des
vector4 utilis´e pr´ec´edemment, par une organisation en SoA avec 3 buffers distincts pour
les coordonn´ees x, y et z, pour un gain de 25% de m´emoire. De plus, nous avons constat´e
que cette organisation m´emoire favorise la coalescence et donc les performances, surtout
pour les architectures plus anciennes. Ainsi, les pr´ec´edentes simulations peuvent aussi
appliquer une organisation m´emoire en SoA afin de r´eduire la consommation m´emoire et
am´eliorer l´eg`erement les performances.
La consommation m´emoire reste une limite, qui nous empˆeche de simuler des syst`emes
tr`es larges avec des GPUs standards dont la capacit´e m´emoire est limit´e. Cependant,
certains GPUs de derni`ere g´en´eration poss`edent jusqu’`a 32Go de m´emoire permettant de
d´epasser cette limite en utilisant notre algorithme. Il existe ´egalement la solution d’utiliser
un cluster de GPU, pour lequel il faudrait adapter notre m´ethode pour ˆetre parall´elis´ee
sur un cluster. Toutefois, mˆeme avec nos ressources actuelles, la parall´elisation sur GPU
de ce type de simulation de SRD-MD permet d’ouvrir des perspectives nouvelles dans
l’´etude de ce mod`ele, acc´el´erant consid´erablement les temps de calcul et permettant une
´etude `a une plus grande ´echelle.
Chapitre 4 : Application de la SRD aux simulations de fluides
Dans le document
Simulations de fluides complexes à l'échelle mésoscopique sur GPU
(Page 88-93)