Architecture et environnement de simulation

LightTM a ´et´e impl´ement´e au-dessus d’un environnement de simulation

multipro-cesseur SPARC.

6.6 ´Evaluation

Les caract´eristiques des plateformes simul´ees sont r´esum´ees dans la table6.3, tandis que

la figure6.11repr´esente une vue sch´ematique des plateformes utilis´ees pour les simulations.

Pour la comparaison des deux syst`emes LightTM, seule l’architecture avec une m´emoire

centrale (architecture 1) est utilis´ee.

TAB. 6.3 – Caract´eristiques des plateformes de simulation

Nombre de processeurs n= 32, (ou 1 `a 32)

Nombre de bancs m´emoire 1

Mod`ele du processeur SPARC-V8 avec FPU, in order

Taille du cache de donn´ees 16Ko

Taille d’une ligne (donn´ees) 8mots (32octets)

Taille du cache d’instructions 16Ko

Taille d’une ligne (instructions) 8mots

Associativit´e du cache Correspondace directe

Taille du tampon d’´ecriture 8mots

Topologie du NoC Mesh 2D

Latence du NoC 10 cycles

D´ef. d’un cycle sur les graphes 200 cycles simul´es

FIG. 6.11 – Plateformes utilis´ees pour les simulations

Afin de suivre cette approche ´ecriture simulatn´ee vs. ´ecriture diff´er´ee, nous avons donc

d´efini deux variantes de cette architecture :

Chapitre 6 ´Etude du protocole de coh´erence pour les m´emoires transactionnelles

– une configuration utilisant un protocole `a ´ecriture simultan´ee `a invalidations (WTI)

avec r´epertoire (configuration ´ecriture simultan´ee, avec les transactions LightTM-WT)

– une configuration utilisant un protocole WB-MESI avec r´epertoire (configuration

´ecriture diff´er´ee, avec les transactions LightTM-WB)

La seconde architecture ne sera utilis´ee qu’avec le protocole `a ´ecriture diff´er´ee.

Chaque simulation utilise un syst`eme comportant de 1 `a 32 processeurs et des caches

L1 `a correspondance directe (avec les instructions s´epar´ees des donn´ees). La coh´erence de

cache est maintenue par le protocole d´efini en fonction de la configuration, au-dessus d’un

NoC `a bande passante ´elev´ee. Le protocole de communication utilis´e entre les diff´erents

composants est bas´e sur VCI, enrichi pour supporter les transactions.

L’environnement de simulation utilise le mod`elecycle-accuratedes composants de la

bib-lioth`eque SoCLib [The08], qui mod´elise pr´ecis´ement les diff´erents composants pr´esents sur

une puce, mais ne supporte pas les m´emoires transactionnelles. Les instructions relatives

aux transactions ont ´et´e ajout´ees dans le mod`ele du processeur, et sont appel´ees par

l’in-term´ediaire de macros C. En r´ealit´e, seul les appels aux fonctions store log address()

et store log size() requi`erent le d´ecodage d’une nouvelle instruction, les instructions

begin transaction()etend transaction()ayant ´et´e cod´ees en utilisant les instructions

rd %asr etmov %asrdu SPARC. Lors d’un abort, une interruption est envoy´ee du cache

vers le processeur, ce qui restaure alors les valeurs des registres sauvegard´ees avant le d´ebut

de la transaction et la recommence.

Chaque application simul´ee a ´et´e compil´ee avec deux configurations : une avec des spin

locks et une avec des transactions. Nous avons utilis´e des spin locks et non des mutex locks

de mani`ere `a ne pas favoriser les transactions : en effet, nous avons suppos´e un contexte

sans commutation de threads, et dans un tel contexte les spin locks sont plus r´eactifs que

les mutex. Nous avons tout de mˆeme effectu´e quelques exp´erimentations avec des mutex

locks, et les r´esultats ont ´et´e bien pire pour les micro-noyaux, et plus lents ou ´equivalents

`a la plus lente des 2 autres configurations pour les benchmarks SPLASH-2 test´es. Les spin

locks utilis´es sont des spin locks mat´eriels id´eaux de 1 cycle impl´ement´es en m´emoire, ne

requ´erant ainsi qu’une requˆete du processeur pour ˆetre pris (le test-and-set ´etant fait par la

m´emoire) ou lib´er´es.

6.6.2 ´Evaluation de l’approche ´ecriture simultan´ee vs. ´ecriture diff´er´ee sur les

micro-noyaux

Avant de simuler les applications, nous avons essay´e de couvrir les cas un peu extrˆemes

de nos syst`emes en utilisant deux micro-noyaux. Nous avons simul´e ces micro-noyaux sur

des architectures de 2 `a 32 processeurs.

6.6.2.1 Premier micro-noyau

Le premier micro-noyau est illustr´e figure 6.12. Dans ce programme, tous les threads

essaient d’acc´eder `a la mˆeme variable partag´ee en parall`ele et de l’incr´ementer. Le

pro-gramme s’arrˆete lorsque la variable a ´et´e incr´ement´e 10 000 fois. Il est ´evident que plus il

y a de processeurs, plus le temps d’ex´ecution est long puisque ajouter des processeurs ne

fait qu’ajouter du trafic. Cependant, ce programme permet d’exhiber le comportement des

deux syst`emes avec une forte congestion.

Sur la figure 6.6.2.1 sont montr´es les temps d’ex´ecution pour les transactions. Ces

r´esultats montrent que LightTM-WT, bien que plus lent, est plus stable que LightTM-WB

quand le nombre de processeurs augmente puisque le temps d’ex´ecution est presque

con-stant. Ainsi, on peut s’attendre `a ce que LightTM-WT ait un meilleur comportement lorsque

6.6 ´Evaluation

1 i n t end = 0 ;

2 i n t s h a r e d v a r = 0 ;

3 while ( end ! = 1 ){

4 b e g i n t r a n s a c t i o n ( ) ;

5 i f ( s h a r e d v a r == 1 0 0 0 0 ){

6 end = 1 ;

7 }

8 e l s e {

9 s h a r e d v a r ++;

10 }

11 e n d t r a n s a c t i o n ( ) ;

12 }

FIG. 6.12 – Premier micro-noyau utilis´e pour ´evaluer les syst`emes TM avec une congestion

´elev´ee

0

1000

2000

3000

4000

5000

6000

7000

8000

5 10 15 20 25 30

T

e

m

p

s

d

'e

xé

cu

ti

o

n

Nombre de Processeurs

Transactions LightTM-WT

Transactions LightTM-WB

FIG. 6.13 – Temps d’ex´ecution pour le premier micro-noyau avec les transactions LightTM

le nombre de processeurs devient tr`es ´elev´e, mˆeme si nous ne sommes pas all´es au-del`a de

32 processeurs dans nos exp´erimentations. Cependant, cela n’est peut-ˆetre pas la forme la

plus repr´esentative d’ex´ecution parall`ele puisque le parall´elisme est tr`es limit´e ; c’est pour

cela que nous avons d´efini un second micro-noyau.

6.6.2.2 Second micro-noyau

Le second micro-noyau que nous avons ´ecrit consiste `a avoir des variables s´epar´ees pour

tous les processeurs, chaque processeur incr´ementant sa propre variable. Afin d’avoir des

r´esultats significatifs, nous avons chang´e le nombre d’incr´ements en fonction du nombre de

processeurs, de telle sorte que le nombre total soit toujours de 10 000.

Nous avons aussi consid´er´e un facteur additionnel : le niveau de parall´elisme inh´erent,

relatif au placement des donn´ees, et en particulier au niveau des blocs m´emoire. Le meilleur

cas consiste `a avoir toutes les variables situ´ees dans des blocs diff´erents, tandis que le pire

cas consiste `a avoir des lignes remplies de variables partag´ees (par exemple dans notre cas

avec 32 processeurs, avoir toutes les variables sur 4 lignes de 8 mots).

Pour ce micro-noyau, nous avons trouv´e int´eressant de comparer les temps d’ex´ecution

des transactions `a leurs ´equivalents `a base de verrous. En ce qui concerne la granularit´e

des verrous, nous n’avons consid´er´e qu’une granularit´e fine, i.e. le cas id´eal o `u chaque

pro-Chapitre 6 ´Etude du protocole de coh´erence pour les m´emoires transactionnelles

cesseur utilise son propre verrou. Mˆeme si cela n’est pas tr`es r´ealiste puisque dans un tel

programme les verrous pourraient alors ˆetre supprim´es, cela reste la situation id´eale pour

les verrous, et vers laquelle les programmes devraient tendre.

Nous avons ainsi pu d´efinir deux versions du micro-noyau :

1. la versioncontig ¨ue(figure6.14(a)),

2. la versionnon-contig ¨ue(figure6.14(b))

1 i n t s h a r e d v a r [NB PROCS ] ;

2 / * I n i t i a l i s a t i o n . . . * /

3 i n t j ;

4 i n t l i m i t = 10000/NB PROCS ;

5 f o r ( j = 0 ; j < l i m i t ; j ++){

6 p t h r e a d s p i n l o c k ( l o c k [

p r o c i d ] ) ;

7 / * ou b e g i n t r a n s a c t i o n ( ) ; * /

8 s h a r e d v a r [ p r o c i d ] + + ;

9 p t h r e a d s p i n u n l o c k ( l o c k [

p r o c i d ] ) ;

10 / * ou e n d t r a n s a c t i o n ( ) ; * /

11 }

(a) Version contig ¨ue

1 i n t s h a r e d v a r [NB PROCS* LINE SIZE ] ;

2 / * I n i t i a l i s a t i o n . . . * /

3 i n t j ;

4 i n t l i m i t = 10000/NB PROCS ;

5 f o r ( j = 0 ; j < l i m i t ; j ++){

6 p t h r e a d s p i n l o c k ( l o c k [ p r o c i d ] ) ;

7 s h a r e d v a r [ p r o c i d * LINE SIZE ]++;

8 p t h r e a d s p i n u n l o c k ( l o c k [ p r o c i d

] ) ;

9 }

(b) Version non-contig ¨ue

FIG. 6.14 – Repr´esentation simplifi´ee du second micro-noyau

Bien que ces 2 cas ne soient pas r´ealistes, nous pensons qu’ils sont assez repr´esentatifs

des possibilit´es d’ex´ecution avec beaucoup de concurrence quand aucune pathologie ne se

met en place.

Les r´esultats de ce micro-noyau sont pr´esent´es sur deux graphes : la figure6.15(a)

con-tient quatre courbes pour l’´ecriture simultan´ee (spin locks ou transactions, contigu ou

non-contigu), tandis que la figure6.15(b)contient les mˆemes courbes pour l’´ecriture diff´er´ee.

0

1000

2000

3000

4000

5000

6000

7000

8000

5 10 15 20 25 30

T

e

m

p

s

d

'e

xé

cu

ti

o

n

Nombre de Processeurs

Spin Locks, Contigu

Transactions, Contigu

Spin Locks, Non-Contigu

Transactions, Non-Contigu

(a) ´Ecriture simultan´ee

0

1000

2000

3000

4000

5000

6000

7000

8000

5 10 15 20 25 30

T

e

m

p

s

d

'

cu

ti

o

n

Nombre de processeurs

Spin Locks, Contigu

Transactions, Contigu

Spin Locks, Non-Contigu

Transactions, Non-Contigu

(b) ´Ecriture diff´er´ee

6.6 ´Evaluation

Les r´esultats montrent que les temps des transactions sont proches de ceux des spin

locks, pour la version contig ¨ue comme pour la version non-contig ¨ue, montrant que les

transactions sont capables d’exploiter le parall´elisme inh´erent de l’application. En fait,

les programmes avec des spin locks sont mˆeme plus lents que les transactions pour

LightTM-WB pour les deux versions, `a cause de requˆetes de prise et de relˆache de verrous

suppl´ementaires. Cela est plus facile `a voir pour la version non-contig ¨ue : une fois qu’une

ligne est dans l’´etatMen cache, les transactions s’enchainent rapidement sans acc´eder `a la

m´emoire principale (les commits sont locaux dans ce cas). Pour la version contig ¨ue, un cache

a le temps de faire plusieurs transactions avant de recevoir une requˆete d’invalidation, c’est

pourquoi le nombre de r´e-´ecritures et de r´ecup´erations de la ligne en cache est inf´erieur au

nombre de transactions, tandis que pour le programme avec des verrous, 2 acc`es non cach´es

sont faits pour chaque transaction.

Avec LightTM-WT cependant, les commits plus lents n’arrivent pas `a compenser les

requˆetes de verrous. N´eanmoins, pour les deux architectures, les courbes des transactions

montre un comportement globalement identique `a celui des spin locks.

Enfin, la comparaison entre l’´ecriture simultan´ee et l’´ecriture diff´er´ee montre que le

LightTM-WB a des meilleurs r´esultats que LightTM-WT pour les deux versions, bien que

ce ne soit pas une surprise ´etant donn´e la nature du micro-noyau.

6.6.3 R´esultats des applications pour l’approche ´ecriture simultan´ee vs. ´ecriture

Dans le document Étude de deux solutions pour le support matériel de la programmation parallèle dans les multiprocesseurs intégrés : vol de travail et mémoires transactionnelles (Page 103-108)