Coût d'exécution d'un cache d'instructions logiciel

Cette section porte désormais sur l'analyse du coût global qui est donne TAcc`es moyen de l'équation 1 (voir section 3.3.1.2, page 30) pour le contexte d'un cache logiciel pour instruc- tions. Le coût complet d'un Miss est maintenant pris en compte, avec le coût total de sa

pénalité incluant l'accès à la Flash NAND, la FTL et la copie de blocs de code dans l'espace de stockage temporaire.

L'unication de tous les paramètres est l'occasion de confronter les résultats des dif- férents composantes d'un cache étudiées jusqu'ici, ainsi que les constats qui ont pu en être dégagés. Nous garderons ainsi la segmentation comme stratégie de placement car elle est la mieux adaptée à notre contexte. De la même manière que dans la section précédente, nous présentons des résultats sur FIFO et LRU, les politiques de remplacement éprouvées et de référence. D'autant que nous avons montré section 4.2.2, page 65, que le gain d'une nouvelle politique n'est pas susamment signicatif dans notre contexte pour en proposer de nouvelles.

Enn, nous avons également montré que, en dehors de la taille du cache, le paramètre tirant le plus vers le haut ou le bas l'ecacité était l'unité de stockage. En résumé des sections précédentes, modier la taille de l'unité de stockage entraîne plusieurs phénomènes qui peuvent se cumuler ou s'annuler :

1. la variation du nombre d'entrées dans le cache ; 2. la dilution spatiale ;

3. la possibilité pour la politique de remplacement de manipuler plus ou moins d'entrées ; 4. l'augmentation ou la réduction de la profondeur de recherche d'une ICa.

4.2.3.2 Résultats expérimentaux

Les résultats sont rassemblés dans la gure 4.11, page 69, pour nos programmes de tests. Le protocole expérimental est même que pour la section 3.4.3. L'axe des ordonnées reste la mesure du CoI exprimée en IOv/ICa, et un point sur une courbe représente un CoI moyen caractérisant le temps TAcc`es moyen. L'axe des abscisses est une variation du nombre d'entrées dans chaque structure de données évaluée (e.g. liste chaînée, table de hachage et arbre rouge-noir). Cependant, les nombres d'entrées données sur les graphiques sont par clarté ceux de  références . Le lecteur peut se reporter au tableau 4.3, page 53, pour trouver la correspondance avec le nombre d'entrées du cas de gure mesuré.

Enn, nous noterons que la taille de l'empreinte est ici de 4096 octets. Sous cette barre, nos programmes de tests sont beaucoup moins performants et les courbes moins explicites. Dans des caches plus petits, les tendances constatées restent les mêmes que celle présentées, mais il est clair que les programmes utilisés sont trop gros pour nos cibles à 1 ou 2 Ko de cache. Pour des programmes natifs de cette taille, il est donc recommandé d'avoir des systèmes matériels un peu moins restreints, comme par exemple des cartes à puce existantes avec 32 Ko de mémoire vive.

4.2.3.3 Évaluation et analyse du coût global

L'analyse globale est rendue dicile à la base par l'interaction de tous les paramètres de cache entre eux, et de la structure de chaque programme. Grâce à l'analyse individuelle de chacun d'eux menée dans les sections précédentes, il est maintenant plus aisé de dépasser l'eet boîte noire que représente un cache en terme d'ingénierie.

On constate ainsi que le CoI moyen d'accès au cache suit les courbes de débits de la section 4.2.2, page 65, mesurant principalement l'impact des défauts de cache. Au nal, le CoI tend à se stabiliser autour d'une unité de stockage optimale comprise entre 128 et 256 octets.

1632 64 128 256 512 50 100 150 200 250 300 350 400 IOv/ICa

RBTREE FIFO DLIST HASH

(a) KVM 1632 64 128 256 512 50 100 150 200 250 300 350 400

RBTREE FIFO DLIST HASH

(b) Richards V7 C++ 1632 64 128 256 512 50 100 150 200 250 300 350 400

Taille de page en octets

IOv/ICa (c) GSM 1632 64 128 256 512 50 100 150 200 250 300 350 400

Taille de page en octets

(d) Rijndael

Figure 4.11: Coût en instructions de l'interface logicielle d'un cache de 4096 octets. Ces points sont légèrement décalés par rapport aux résultats sur le débit du fait cette fois de l'interaction des algorithmes de recherche et du temps complet de la pénalité d'un Miss. Il est intéressant de noter que nos programmes de test tendent tous vers ce même point de stabilité malgré leurs structures, propriétés et diérences respectives. Certes, tous n'atteignent pas le même niveau d'ecacité, mais leurs meilleurs niveaux respectifs tournent autour de ce point.

Ces résultats montrent également que les stratégies de recherche et de renouvellement LRU présentent désormais des diérences mineures car leur coût est absorbé par le coût total.

Mais la principale information que ces résultats apportent est l'écart qui subsiste entre un cache et une mémoire adressable. Dans celle-ci, le processeur accède à une instruction en un cycle, alors qu'il lui en faut encore au moins 50 en moyenne avec un cache de notre échelle. Certes, un cache comble l'écart avec la NOR, puisque celui-ci se réduit par rapport au 2 ∗ 2048 octets de tampons comparables (eux-même 73 fois plus lent que la Flash NOR en moyenne).

Pour clore ce chapitre, nous terminons sur un dernier constat en lien avec le précédent qui sera fondamentale dans notre approche présentée chapitre 6. Le coût principal d'un cache implémenté en logiciel n'est pas la latence de la mémoire secondaire et les défauts de

cache, lorsque ce dernier est relativement bon dans cet exercice. Le goulot d'étranglement dans ce type de cache est le nombre d'accès.

La gure 4.12 présente pour chaque algorithme d'accès et pour chaque unité de stockage la part que représente dans le CoI d'accès moyen :

• une recherche avec succès et la gestion d'un Hit, en vert ; • une recherche avec échec et la gestion d'un Miss, en brun.

RBTREE DLIST HASH RBTREE DLIST HASH RBTREE DLIST HASH RBTREE DLIST HASH RBTREE DLIST HASH RBTREE DLIST HASH

20 40 60 80 100 16 32 64 128 256 512 P ourcen tage % Hit Miss

Figure 4.12: Répartition des coûts en instructions d'un succès et d'un défaut de cache. Ces résultats proviennent cette fois du programme de test Richards-V7-C++, qui est le plus proche en terme de structure de code de ce que sont les applications JavaCard. On constate que le coût d'accès moyen pour les meilleures unités de stockage est largement dominé par l'accès à des données déjà présentes en cache.

Cela signie qu'il passe donc le plus clair de son temps à servir et resservir des données présentes désormais dans la mémoire vive, elle-même adressable et accessible en temps constant. Ce qui est paradoxal, puisque c'est exactement l'endroit et les conditions les plus favorables pour la meilleure performance d'un opérateur d'exécution. Dans ces conditions, le cache forme donc bel et bien une barrière entre la lecture de ces données et leur présence eective en mémoire vive.