Conditions expérimentales

Programme de test. Les expérimentations sont menées sur dix programmes de test et deux tâches d’une application réelle. Les programmes de test utilisés sont les WCET benchmarks maintenus par le groupe de recherche en WCET de Mälardalen [62]. Les tâches réelles sont issus d’une application réelle nommée debie [28] fournie par le Space Systems Finland Ltd (SSF) s’exécutant sur satellite afin de mesurer l’impact des micro-météorites et petit débris. Le tableau2.3donne les caractéristiques de chacun des programmes de test ainsi que des tâches de debie utilisées.

Analyse de caches et estimation du pire temps d’exécution. Les expé- rimentations sont menées sur du code binaire compilé avec gcc 4.1 sans optimi- sation pour du MIPS R2000/R3000 [66]. L’estimation du pire temps d’exécution est calculé par le logiciel HEPTANE [24] en utilisant la méthode d’énumération implicite des chemins (IPET). Les analyses Must, May et Persistence sont ap- pliquées sur chaque niveau de la hiérarchie de cache. L’analyse est contextuelle et de fait l’analyse est effectuée pour chaque fonction sur chacun des contextes d’appels.

74 Analyse du contenu des hiérarchies de caches

Nom Description Taille

du code

(octets) matmult Multiplication de matrices 50x50 composées de nombre en-

tiers

1200

ns Recherche dans un tableau multi-dimensionel 600

bs Recherche binaire dans un tableau de 15 entiers 336

minver Inversion d’une matrice 3x3 composée de nombre flottants 4408

jfdctint Transformée en cosinus discrète 3040

crc Contrôle de redondance cyclique 1432

qurt Calcul des racines d’équations quadratiques 1928

fft Transformée de Fourier rapide 3536

adpcm Encodage de la voix 7740

statemate Code généré automatiquement par STARC (STAtechart

Real-time-Code generator)

8900 health monitoring Vérification périodique de l’état du système, incluant la ré-

cupération de valeurs des capteurs.

14944 telecommand Traitement et répartition vers les composants concernés des

commandes reçues à distance

14824

Tab. 2.3: Caractéristiques des programmes de test

Pour séparer l’effet des caches des autres mécanismes matériels, l’estimation du pire temps d’exécution considère uniquement la contribution des accès mé- moire au pire temps d’exécution comme présentée dans la section 2.7. Les effets des autres mécanismes matériels ne sont pas pris en compte. En particulier, nous ne prenons pas en compte les anomalies temporelles causées par les interactions entre les caches et les pipelines. La classification de comportement Not Classified peut alors être considérée comme ayant le même comportement pire cas que la classification Always-Miss pendant le calcul de l’estimation du pire temps d’exé- cution. Finalement, l’analyse débute en considérant un état de cache vide ce qui est sûr en absence d’anomalies temporelles en utilisant une politique de remplace- ment de cache LRU et pour les politiques de remplacement non-LRU en utilisant les bornes mls/evict définies indépendamment du contenu initial du cache. Environnement de mesures. Les mesures effectuées dans le pire scénario d’exécution utilisent un simulateur de jeu d’instructions MIPS [70]. En raison de la difficulté à identifier les données d’entrées conduisant à la pire situation pour les programmes complexes, nous comparons l’estimation du pire temps d’exécu- tion avec les valeurs mesurées uniquement pour les programmes de test simples (matmult, ns, bs, minver, jfdctint). Tous ces programmes de test sont à chemin unique sauf bs qui est suffisamment simple pour identifier ces données d’entrées conduisant au pire scénario d’exécution.

Expérimentations 75 Le simulateur a été étendu pour supporter une hiérarchie de cache constituée de trois niveaux avec les différentes politiques de gestion : non-inclusive, inclu- sive et exclusive. En raison des effets dominos [13] pouvant se produire avec les politiques de remplacement de cache non-LRU, l’estimation du pire temps d’exé- cution est comparée uniquement avec les mesures effectuées avec la politique de remplacement de cache LRU. Pour les autres politiques de remplacement de cache, trouver le pire temps d’exécution même dans le cas de programme à che- min unique requière une exploration exhaustive de tous les états initiaux de cache ce qui est évidemment trop coûteux.

Configuration de cache. Les expérimentations sont menées en utilisant une hiérarchie de caches composée de deux niveaux avec différentes configurations de cache résumées dans le tableau2.4. Nous utilisons deux groupes de configurations avec différentes tailles de cache (small-32-32 et small-32-64 pour les programmes de test ; medium-32-32 et medium-32-64 pour debie). Pour chaque groupe, les deux configurations sont différenciées par la taille des lignes de cache du second niveau (L2). Les configurations avec les mêmes tailles de lignes de cache dans le cache de premier (L1) et de second niveau (L2) sont utilisées pour détecter si l’analyse statique de cache capture la localité temporelle au niveau du L2. Les configurations avec des tailles de lignes différentes sont quant à elles utilisées pour détecter si l’analyse statique de cache capture les deux types de localité, spatiale et temporelle, au niveau du L2.

Taille du cache Taille des lignes de cache Associativité

L1 L2 L1 L2 L1 L2

small-32-32 1KB 2KB 32B 32B 4 8

small-32-64 1KB 2KB 32B 64B 4 8

medium-32-32 8KB 16KB 32B 32B 4 8

medium-32-64 8KB 16KB 32B 64B 4 8

Tab.2.4: Les différentes configurations de cache

Métriques. Afin d’évaluer la précision de notre approche, la comparaison du taux de succès dans le cache L2 entre l’analyse statique et les mesures n’est pas appropriée en raison du pessimisme inhérent à l’analyse statique du cache L1, introduisant des accès au niveau du cache L2 lors de l’analyse ne se produisant en pas nécessairement lors de l’exécution. À la place, nous utilisons les trois métriques suivantes :

a. Le nombre d’accès et le nombre de défauts de cache se produisant dans chaque niveau de la hiérarchie. Ces valeurs sont fournies pour l’analyse

76 Analyse du contenu des hiérarchies de caches statique et pour les valeurs obtenues par mesure lors de l’exécution de la tâche dans le pire scénario d’exécution ;

b. La contribution au pire temps d’exécution des accès mémoire. Afin de mon- trer l’intérêt d’une analyse multi-niveaux, deux valeurs sont données : une en considérant la hiérarchie de cache (L1+L2) et l’autre en ignorant le cache L2 (dans ce cas tous les accès au L2 sont considérés comme produisant des défauts de cache). Des latences de 1 cycle pour le L1, de 10 cycles pour le L2 et de 100 cycles pour la mémoire principale sont utilisées. Lorsque le L2 est ignoré lors de l’analyse, la latence mémoire considérée est de 110 cycles ; c. L’amélioration/dégradation relative de la contribution des accès mémoire au pire temps d’exécution. Cette valeur est calculée pour une configura- tion de cache analysée comparée à une configuration de cache de référence. La configuration de référence est toujours celle disposant d’une politique de gestion non-inclusive (NI) avec la même politique de remplacement de cache que la configuration analysée (Analysisevaluated

AnalysisN I − 1). Plus cette valeur

est petite, plus le résultat de l’analyse de cache de la configuration analysée est meilleur comparativement à la configuration de référence.