Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne fait partie de son cours d’introduction à l’information, à la communication, et au calcul. Il s’inscrit dans le 3e module de ce cours qui porte sur le fonctionnement et la sécurité des systèmes informatiques.

Où en sommes-nous ? Technologie des mémoires Hiérarchie de mémoires Concept Objectif Réalisation Lecture Ecriture Gestion LRU Exemple Pourquoi – Localité L’exemple du videoclip précédent a montré pratiquement que l’algorithme LRU est un bon prédicteur du bloc à éjecter de la cache quand elle est pleine … … mais cela n’explique pas pourquoi ses prédictions sont bonnes. Expliquer ce pourquoi est le but de ce dernier clip sur le sujet.

Revoyons de plus près la boucle de la somme de n entiers somme des premiers n entiers entrée : n sortie : m s  0 tant que n > 0 s  s + n n  n – 1 m  s Rejetons un œil sur la boucle de l’algorithme de sommation des N premiers entiers que nous avons utilisé comme exemple dans le clip précédent pour illustrer les prédictions LRU.

1er phénomène: Accès répétés à des addresses identiques Proc Tant que n > 0 s  s + n n  n – 1 lire @13 (en cache dans n-1 cas) charger bloc @12 placer bloc @12 retourner 2 lire @14 (en cache) retourner 0 lire @13 (en cache) somme s, n (0 + 2) écrire 2 @14 (en cache) somme n, -1 (2 – 1) écrire 1 @ 13 (en cache) On observe dans chaque exécution de cette boucle un 1er phénomène: En le bref laps de temps de l’exécution de la boucle, le processeur accède 2x à s et 4x à n … … et cette boucle peut être répétée des centaines voire des milliers de fois ou plus. cache 12 n s ? mémoire principale 4 8 12 m n s

C’est ce qu’on appelle la localité temporelle En cache parce qu’il y a eu des accès à la même variable à des instants rapprochés dans le temps C’est typique de la réalité Tous les algorithmes “intéressants” accédant de façon répétée aux mêmes variables (Pendant une semaine à la neige, on réutilise son snowboard tous les jours) En termes clairs, le processeur réaccède de très nombreuses fois aux mêmes variables pendant une fenêtre de temps non-négligeable. Cette observation n’est pas un hasard mais une réalité typique de la quasi totalité des programmes. Tous les programmes implémentant des algorithmes intéressants comportent des boucles qui réaccèdent de nombreuses fois aux mêmes variables au cours de leur exécution. Le groupe de variables auxquelles un programme réaccède peut certes évoluer lentement au cours de son exécution mais cette «localité temporelle», puisque tel est son nom, existe bel et bien surtout au sein des nombreuses boucles, même si elle évolue progressivement entre ces boucles. En termes de bagages de vacances de neige, on a besoin de son snowboard tous les jours. Donc il est intéressant de l’emporter en sachant qu’il sera intensément utilisé. 12 n s

1er phénomène: Accès consécutifs à des addresses proches Tant que n > 0 s  s + n n  n – 1 lire @13 charger bloc @12 placer bloc @12 retourner 2 lire @14 (en cache) retourner 0 lire @13 (en cache) somme s, n (0 + 2) écrire 2 @14 (en cache) somme n, -1 (2 – 1) écrire 1 @ 13 (en cache) On observe par ailleurs un 2nd phénomène dans l’exécution de ce programme: Le programme accède typiquement à des variables – n et s – qui se trouvent non seulement impliquées dans les mêmes calculs mais de ce fait aussi situées à des adresses tombant dans les mêmes blocs de la mémoire – 12 dans le cas présent. cache 12 n s ? mémoire principale 4 8 12 m n s

C’est ce qu’on appelle la localité spatiale En cache parce qu’il y a eu des accès à des variables différentes mais à des adresses rapprochées dans l’espace C’est typique de la réalité Tous les algorithmes “intéressants” travaillent avec une série de variables liées entre elles (Si on va skier, on a besoin du ski gauche et du ski droit … et des bottines associées) En termes clairs encore une fois, le processeur accède quasi simultanément à des variables qui sont logiquement impliquées dans les même calculs et donc typiquement co-situées. Cette observation n’est pas non plus un hasard mais une réalité typique de tous les programmes. Tous les programmes implémentant des algorithmes intéressants manipulent ensemble des groupes de variables liées aussi bien conceptuellement que physiquement. Les groupes de variables auxquelles un programme accède évoluent certes au cours de son exécution mais cette «localité spatiale», puisque tel est son nom, existe bel et bien dans tout programme. En termes de bagages de vacances de ski, on a besoin tous les jours non seulement du ski gauche mais aussi du ski droit car ils font partie du même programme. Il est donc intéressant d’emporter les deux en sachant qu’ils seront toujours utilisés ensemble. 12 n s

Et si les blocs étaient plus petits Proc 2 mots au lieu de 4 Plus de petits blocs en cache n et s seraient dans des blocs différents => Cela causerait 2 défauts de cache au lieu de 1 => Moins de localité spatiale mais … … performance maintenue avec une cache plus petite Parlant de variables co-situées dans les mêmes blocs on peut se demander ce qui arriverait si on prenait des blocs plus petits, p.ex. de 2 mots au lieu de 4. 1 Cela permettrait d’accommoder plus de blocs plus petits dans une cache de même taille. 2 Par contre n et s atterriraient dans des blocs différents, 3 ce qui causerait 2 défauts de cache au lieu d’un seul. 4 La localité spatiale en souffrirait … … mais on pourrait maintenir la performance avec une cache plus petite. cache 12 n 14 s mémoire principale 2 : 12 14 m : : n s

Et si les blocs étaient plus grands Proc 8 mots au lieu de 4 Moins de grands blocs en cache m, n, et s ne peuvent pas être en mémoire en même temps => Cela causerait 2 défauts de cache au lieu de 1 à chaque exécution du programme => Moins de localité temporelle mais … … performance maintenue avec une cache plus grande Inversement on peut se demander ce qui arriverait si on prenait des bloc plus grands, p.ex. de 8 mots au lieu de 4. 1 Cela permettrait d’accommoder moins de blocs plus grands dans une cache de même taille. 2 Par contre m, n et s ne pourraient plus se retrouver en cache en même temps, 3 ce qui causerait aussi 2 défauts de cache au lieu d’un seul à chaque exécution du programme. 4 Donc ici c’est la localité temporelle qui souffrirait … … mais on pourrait maintenir la performance avec une cache plus grande. cache 8 n s s mémoire principale 8 m n s s

Localité spatiale & temporelle vs. taille des blocs Beaucoup de petits blocs Meilleure localité temporelle Moins bonne localité spatiale Quelques grands blocs Meilleure localité spatiale Moins bonne localité temporelle Plus de défauts de cache Blocs plus grands Au final on voit que si on réduit la taille des blocs cela favorise la localité temporelle mais nuit à la localité spatiale … et vice versa. Quelque part il doit donc y avoir une taille de blocs optimale pour laquelle le nombre de défauts de cache est minimal. Cet optimum dépend cependant de la taille de la cache et du comportement du programme. Or quand on construit un ordinateur on doit fixer la taille de sa cache et celle de ses blocs. Il y a donc peut de chance que les choix du constructeur soient optimaux pour TOUS les programmes. L’important est qu’ils soient proches de l’optimum pour le mélange de programmes qui vont typiquement tourner dessus ledit ordinateur, ce qui est heureusement le cas dans la pratique courante. Optimum dépendant de la taille de la cache et de la nature du programme