Environnement de simulation et m´ethodes de validation des syst`emes existants 67

RTM[SSH+

07] est un syst`eme hybride qui impl´emente au niveau mat´eriel les diff´erentes

cat´egories de syst`emes HTM, tout en laissant le choix de la politique au niveau logiciel.

L’avantage de cette approche, couteuse au niveau mat´erielle, est qu’elle permet facilement

de d´efinir des politiques de r´esolution des conflits avanc´ees, et de basculer entre diff´erents

sch´emas de d´etection. RTM se base sur un protocole de coh´erence `a ´ecriture diff´er´ee, dans

lequel cinq ´etats sont ajout´es aux quatre traditionnels pour une ligne de cache. En raison de

la gestion logicielle des d´ebordements, les performances se d´egradent rapidement lorsque

les transactions d´ebordent des structures mat´erielles.

FlexTM [SDS08] est une am´elioration de RTM dans laquelle est ajout´e un dispositif

mat´eriel pour la gestion de signatures. La d´etection des conflits est aussi d´ecoupl´ee de la

gestion des versions, ce qui n’´etait pas le cas dans RTM. Enfin, le protocole transactionnel

est simplifi´e puisqu’il ne comporte plus que deux ´etats suppl´ementaires.

TokenTM[BGH+

08] est un syst`eme EE qui utilise l’abstraction des jetons pour garantir

la coh´erence des donn´ees et d´etecter les conflits. L’avantage de cette approche est qu’elle

per-met d’´eviter les faux positifs comme dans le cas des signatures. Le cas de partage d’une ligne

en lecture `a la fois en dehors et `a l’int´erieur d’une transaction, g´en´eralement imm´ediat dans

les syst`emes EE, est ici complexe mais possible par l’interm´ediaire d’un m´ecanisme

com-pliqu´e de fission et de fusion des ´etats transactionnels. TokenTM supporte les changements

de contexte grˆace au niveau d’abstraction des jetons, mais le cout mat´eriel de ce syst`eme est

relativement ´elev´e.

FASTM [LMG09] est un syst`eme EE similaire `a LogTM-SE, avec pour diff´erence une

modification du protocole de coh´erence permettant d’avoir des aborts rapides – i.e. sans

parcours de log – dans le cas o `u la transaction qui aborte n’a pas d´epass´e la capacit´e du

cache L1. Pour ce faire, les valeurs modifi´ees pr´e-transactionnelles sont propag´ees vers les

niveaux inf´erieurs de la hi´erarchie m´emoire de mani`ere `a garder le plus possible les valeurs

sp´ecul´ees dans le cache L1.

5.6 Environnement de simulation et m´ethodes de validation des

syst`emes existants

La majorit´e des syst`emes pr´esent´es utilisent l’environnement de simulation Simics

GEMS [MSB+

05], qui permet de mod´eliser et de simuler des syst`emes multiprocesseurs.

L’approche consiste `a d´ecoupler la simulation du temps et celle des fonctionnalit´es. De plus,

certains composants mat´eriels ont des mod`eles temporels qui ne sont qu’approximatifs. En

ce sens, le niveau d’abstraction utilis´e est diff´erent de celui que nous visons dans notre ´etude,

et les m´ethodes de validation utilis´ees ne s’appliquent pas `a notre contexte.

Les autres syst`emes utilisent des mod`eles de pr´ecisions du mˆeme ordre, en g´en´eral par

l’interm´ediaire de simulateurs pilot´es par ´ev`enements. Ces mod`eles sont dans tous les cas

moins pr´ecis que les simulationscycle-accurate.

5.7 Conclusion

Si les syst`emes r´ecents ont port´e l’accent sur la virtualisation des transactions, n´ecessaire

pour l’adoption du mod`ele dans le monde r´eel, peu de travaux ont ´etudi´e des propri´et´es

de plus bas niveau. En particulier, la supposition d’un protocole de coh´erence `a ´ecriture

diff´er´ee est toujours faite. Par ailleurs, peu de travaux se sont int´eress´es `a l’implantation

d’un syst`eme TM sur un MPSoC. [FMB+

07] aborde la question, mais avec des hypoth`eses

Chapitre 5 ´Etat de l’art sur les m´emoires transactionnelles

jamais de ce cache) et des exp´erimentations faibles. [GAG08] analyse un protocole avec

d´etection des conflits au niveau du r´epertoire, mais demande un cout mat´eriel tr`es ´elev´e :

associer un num´ero de s´erie `a chaque transaction, et pouvoir enregistrer un num´ero par

processeur et par ligne de cache.

Nous nous proposons premi`erement d’aborder ce probl`eme en concevant, impl´ementant

et comparant d’un point de vue performances deux impl´ementations d’un syst`eme TM

visant les MPSoCs : l’une bas´ee sur un protocole `a ´ecriture simultan´ee, et l’autre bas´ee sur

un protocole `a ´ecriture diff´er´ee. Dans ce but, les hypoth`eses que nous ferons par rapport aux

points ´enonc´es dans cette section seront les suivantes :

– S´emantique d’entrelacement `a plat

– Support pour les grandes transactions (i.e. qui d´ebordent du cache) mais pas de

virtu-alisation

– Pas d’op´erations d’E/S dans les transactions

– Atomicit´e forte vis-`a-vis des acc`es non-transactionnels

Dans un second temps, nous nous int´eresserons `a des variantes du syst`eme bas´e sur le

protocole `a ´ecriture diff´er´ee, notamment au niveau de la politique de r´esolution des conflits,

et nous les comparerons selon deux types de crit`eres : performances et robustesse, au sens

de la r´esistance aux pathologies et aux garanties apport´ees vis-`a-vis de la terminaison.

Chapitre 6

´Etude du protocole de coh´erence pour

les m´emoires transactionnelles

D

ANSce chapitre, nous allons aborder la question de l’implantation d’un syst`eme TM

mat´eriel avec les contraintes d´efinies pr´ec´edemment, en vue d’´etudier la viabilit´e du

mod`ele de programmation transactionnel dans le domaine de l’embarqu´e. Cela sera fait par

l’interm´ediaire de la comparaison de deux syst`emes HTM : un syst`eme original bas´e sur

un protocole `a ´ecriture simultan´ee et un plus traditionnel bas´e sur un protocole `a ´ecriture

diff´er´ee.

6.1 Introduction

Le mod`ele de programmation apport´e par les m´emoires transactionnelles permet de

faciliter l’´ecriture de programmes parall`eles corrects. Cela implique ´evidemment que le

syst`eme sous-jacent doit faire le traitement n´ecessaire pour garantir les propri´et´es des

trans-actions. Aussi, de tels syst`emes sont complexes, en particulier lorsqu’ils sont implant´es en

mat´eriel. Or, cela doit ˆetre le cas, au moins en partie, pour que les programmes reposant sur

ces syst`emes soient performants.

Un syst`eme TM mat´eriel est toujours intimement li´e au protocole de coh´erence de cache,

puisque ce dernier va partiellement d´efinir les ´etats des lignes de la m´emoire. Comme le

domaine de l’embarqu´e remet en cause la supr´ematie du protocole `a ´ecriture diff´er´ee, en

particulier avec l’arriv´ee des NoCs, il est l´egitime de se demander si un syst`eme HTM peut

ˆetre implant´e au-dessus d’un tel protocole, auquel cas se pose le probl`eme de savoir

com-ment les deux implantations se comparent l’une `a l’autre, en termes de performances et de

cout.

Cette partie fait trois contributions :

– La conception d’un syst`eme TM mat´eriel bas´e sur des caches `a ´ecriture simultan´ee

dans lequel l’information relative aux donn´ees acc´ed´ees dans la transaction est

en-registr´ee au niveau du r´epertoire (i.e. la d´etection de conflits est faite au niveau

du r´epertoire). `A notre connaissance, aucun syst`eme bas´e sur ces id´ees n’a ´et´e

pr´ec´edemment propos´e.

– Une comparaison au niveau cycle entre une impl´ementation de ce syst`eme et une

impl´ementation d’un syst`eme TM mat´eriel plus classique bas´e sur une coh´erence `a

´ecriture diff´er´ee - en dehors du protocole de coh´erence de cache, les architectures sont

identiques.

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

diff´er´ee, qui montre que la distribution physique des bancs m´emoire peut mener `a

des gains importants pour les applications ayant une congestion ´elev´ee.

Dans la suite de ce chapitre, nous nous r´ef´ererons au syst`eme TM `a ´ecriture simultan´ee

par LightTM-WT, tandis que le syst`eme TM `a ´ecriture diff´er´ee sera appel´e LightTM-WB, le

nom LigthTM sera quant `a lui utilis´e pour r´ef´erencer les deux syst`emes. Ce nom refl`ete les

choix de conception et hypoth`eses faites dans le but de viser le domaine de l’embarqu´e.

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 84-87)