Cumul du trafic généré, il inclue toutes les requêtes et toutes les réponses

4.3.2.1 Analyse des résultats

Temps d’exécution : contrairement à nos attentes, le protocole WTI offre des moins bonnes

performances que le protocole WB-MESI dans la plupart des applications testées.

Néan-moins, la différence de performance ne dépasse pas les 20% et est en général inférieure à

10%.

D’une manière similaire, le protocole WTI offre un gain faible en temps d’exécution pour

les applicationsocean-cetocean-nc.

4.4 Conclusion de l’étude

Trafic généré : le trafic généré est, dans son ensemble, similaire pour les deux protocoles.

D’après la littérature et les tests préliminaires avec l’application simple_test, nous

de-vrions avoir une quantité de trafic générée bien supérieure pour le protocole WTI que pour

le protocole WB-MESI. Néanmoins, nous observons que la différence de trafic est faible pour

raytracer,ocean-nc,ocean-cetmjpeg. Cette différence ne dépasse pas les 20%.

La plus grosse différence observée en terme de trafic est pour l’applicationwater-nsoù

le protocole WTI génère 4 fois plus de trafic que le protocole WB-MESI. Notons par ailleurs

que dans certains cas le protocole WTI génère moins de trafic que le protocole WB-MESI,

c’est le cas pourocean-c,ocean-ncetraytracer(32 processeurs).

4.3.2.2 Conclusions sur les applications

Nous avons constaté que :

– Le protocole WTI offre des performances similaires au protocole WB-MESI bien

qu’étant un peu en retrait.

– Le trafic généré par le protocole WTI est jusqu’à 4 fois supérieur à celui généré par le

protocole WB-MESI

Il convient de relativiser ces résultats, qui au premier abord, ne semblent pas très bons.

Rappelons tout d’abord qu’un des principaux avantages du protocole WTI est sa simplicité

de mise en œuvre.

Deuxièmement, nous avons montré ici que ce protocole était tout à fait comparable à

notre implantation WB-MESI en terme de performances contrairement à ce que présageaient

les différentes études mentionnées.

4.4 Conclusion de l’étude

Nous avons réalisé tout au long de ce chapitre une étude comparative des protocoles

write-through invalidate (WTI)etwrite-back invalidate (WB-MESI). Nous en avons réalisé des

implantation précises au niveau CABA, que nous avons comparé à l’aide de la simulation

d’architectures multiprocesseurs à mémoire partagée et distribuée.

L’utilisation d’une application de test contrôlée et synthétique (sans système

d’exploi-tation) nous a permis de montrer un gain en performances dans certaines situations. Dans

les systèmes où les données sont suffisamment distribuées, le protocolewrite-through

inva-lidatea l’avantage sur le protocolewrite-back invalidatecar il permet de diminuer la latence

moyenne des accès. Par ailleurs, le trafic généré est certes plus important, mais il n’est pas

suffisant pour créer de la congestion sur un NoC.

L’exécution d’applications plus complexes et réalistes avec un système d’exploitation

montre des résultats plus mitigés. Le protocolewrite-through invalidate s’avère légèrement

moins performant que le protocole write-back invalidate avec une augmentation du temps

d’exécution de l’ordre de 10%. En revanche, le trafic généré est moins important que prévu.

Dans la plupart des applications il est du même ordre de grandeur que celui du protocole

write-back invalidate.

Nous avons finalement montré qu’un protocole de cohérence mémoire très simple

comme le write-through invalidateoffre des performances très comparables à un protocole

beaucoup plus complexe. De plus, dès lors que les accès sont distribués sur plusieurs bancs

mémoires, le trafic généré ne pénalise pas les performances du système.

4.5 Limitations de l’étude

L’étude réalisé s’est basée sur l’utilisation d’un simulateur précis. Ceci permet d’évaluer

le protocole de cohérence en prenant en compte le système dans son intégralité : schémas

d’accès aux données, détails de la micro-architecture, partage des données et du code au

niveau du système d’exploitation, des bibliothèques et de l’application.

En contre partie, nous avons évalué et comparé le protocole à travers son implantation.

Il en découle une question fondamentale : qu’avons-nous évalué, le protocole ou bien son

implantation ? Dans la suite de nos travaux, nous apporterons une réponse à cette question.

Chapitre 5

Méthodes d’évaluation et de

comparaison des protocoles de

cohérence

N

O

us présentons dans ce chapitre une description non exhaustive des différentes

tech-niques d’évaluation des protocoles de cohérence mémoire.

5.1 Modèles théoriques

Jusqu’au début des années 90, la puissance de calcul nécessaire à la simulation

d’ar-chitectures matérielles complètes (processeurs, mémoires, réseaux d’interconnexion, etc.)

n’était pas disponible. C’est pour cela que les premières études [AAHV91, QY89, CF78,

PP84] sur les protocoles de cohérence ont été réalisées à l’aide de méthodes analytiques

et statistiques.

Afin de simplifier le problème, ces analyses reposent sur des hypothèses qui sont très

contraignantes et peu réalistes dans la pratique. Les modèles utilisés pour représenter la

distribution des accès à la mémoire sont bien souvent peu représentatifs du comportement

d’un programme. De même, ces modèles négligent souvent l’accès aux instructions.

Ces méthodes ne permettent pas d’évaluer l’influence des détails de l’architecture et

donnent une vue très abstraite d’un système. Néanmoins, la comparaison des protocoles se

faisant avec les mêmes hypothèses et contraintes, elle permettait de dégager des tendances

et des rapports de performance.

5.2 Simulations dirigées par les traces(trace driven)

Dès le début des années 90 on vit apparaître les premiers modèles de simulation. Ceux-ci

n’exécutaient pas du code à la volée, mais rejouaient les traces d’exécutions obtenues sur une

vraie machine. Ces simulateurs modélisent précisément la hiérarchie mémoire et permettent

d’évaluer le coût d’exécution en cycles d’horloge de chaque instruction.

5.2.1 Architectures monoprocesseurs

Ces simulateurs ne feraient pas d’erreurs d’appréciation si le déroulement de l’exécution

dépendait uniquement du programme exécuté. Néanmoins, certains évènements

indépen-dants du programme, comme les interruptions, sont difficiles à modéliser et font perdre de

la précision au simulateur. Malgré cela, ces modèles de simulation sont très précis pour les

architectures à un seul processeur.

Des études [YRC

+

00,GH93] montrent les limites de cette approche, en particulier pour

les plateformes multiprocesseurs.

5.2.2 Architectures multiprocesseurs et « effet papillon »

Dans une application une partie du contrôle dépend des données. Ceci est un véritable

problème pour l’évaluation des architectures multiprocesseurs.

En effet, si le chemin des instructions est défini par la valeur d’une donnée qui est

modi-fiée par un autre processeur, alors la date de modification de la donnée aura une influence

sur le chemin suivi.

Dans la figure5.1 un branchement dépend de l’évaluation d’un test sur une variable.

Le chemin bsera exécuté sur le processeur 1 seulement si la variablev est modifiée par le

processeur numéro 2 avant que le test ne soit effectué.

F

IG

. 5.1 – Exemple où le contrôle du chemin d’exécution dépend des données.

Dans le document Etude de méthodes et mécanismes pour un accès transparent et efficace aux données dans un système multiprocesseur sur puce (Page 50-54)