Optimisation de cache d'instructions par analyse statique

Transcription

1 Ecole Normale Supérieure de Lyon Rapport de stage de Licence Optimisation de cache d'instructions par analyse statique Pascal Vanier sous la direction de Benoit Boissinot E.N.S. Lyon Fabrice Rastello E.N.S. Lyon Du 4 juin au 13 juillet 2007 Compsys

2 Table des matières 1 Présentation 3 2 Introduction 3 3 Motivations 4 4 Etat de l'art Call-Graph par Pettis et Hansen [5] Temporal Relationship Graph par Gloy et Smith [3] Minimisation de l'expansion de code de l'algorithme de Gloy et Smith [3] par Bouchez et al. [4] Travail eectué Objectifs Notions utiles Basic Bloc Chaînes de Markov Le graphe de ot de contrôle Le graphe de destination Simulation d'exécution Une simplication du problème Conclusions 11 7 Remerciements 12 Références 12 2

3 1 Présentation Mon stage s'est déroulé au Laboratoire d'informatique du Parallèlisme de l'ens Lyon, plus précisément dans l'équipe Compsys, sous la direction de Benoit Boissinot et de Fabrice Rastello. L'objectif de l'équipe Compsys est le développement de techniques d'optimisation spéciques au processus de compilation pour les systèmes embarqués. Cette équipe travaille en partenariat avec STMicroelectronics qui produit les processeurs embarqués "st200" qui sont ceux sur lesquels nos optimisations vont être appliquées. 2 Introduction Dans un monde parfait, les machines seraient équipées de grandes quantités de mémoire à vitesse d'accès très élevée, mais ce n'est pas le cas : dans la réalité, plus la mémoire est rapide, plus elle coûte cher. Ainsi pour faire le lien entre la mémoire à grande capacité (Disques durs et autres supports de stockage) et les registres du processeur, nous avons besoin de mémoires faisant le compromis entre la vitesse d'accès, la taille et le coût. Le processeur n'ayant accès qu'aux registres, les informations sont rapatriées au fur et à mesure des mémoires les plus lentes vers les mémoires les plus rapides. Une information utilisée fréquemment devrait donc être laissée au niveau des mémoires rapides, c'est à dire qu'il faut empêcher qu'elle ne soit remplacée par d'autres informations. Dans ce stage, nous avons travaillé sur la mémoire cache du cache d'instructions des processeurs de type "st200" fabriqués par STMicroelectronics. Le code doit être chargé dans le cache d'instructions pour pouvoir être exécuté, cependant sa taille ne permet pas en général de charger tout le programme. Un chunk est un bout de code de taille inférieure ou égale à une ligne de cache, on parle de conict-miss lorsqu'un programme a besoin d'exécuter un chunk qui a été remplacé par un autre dans le cache d'instruction. Il est alors nécessaire de le copier à nouveau de la mémoire vers le cache, ce qui se traduit par une perte de performance d'environ 150 cycles pour les processeurs sur lesquels nous travaillons. Un chunk peut être remplacé par un autre dans le cache d'instructions si ceux-ci sont à des adresses i 1 et i 2 en mémoire telles que i 1 i 2 [L] (avec L la taille du cache d'instructions. Pour ce faire, on peut changer la place des procédures dans la mémoire et rajouter des espaces vides an de décaler les procédures. L'intérêt de minimiser les conict-miss est évident. L'autre contrainte du problème est de ne pas avoir une taille de programme trop grosse après le placement du code, car étant donné que les programmes sont destinés à des plateformes embarquées ils seront stockés sur de la mémoire ash qui est très coûteuse. 3

4 3 Motivations Il existe deux sortes de caches : les associatifs et les direct-mapped. Dans les premiers une information peut se trouver dans n'importe quelle place du cache, mais la contrepartie est qu'ils nécéssitent un grand nombre de comparateurs physiques et donc consomment plus. Le cache sur lequel nous travaillons est dit direct-mapped, c'est à dire que si L est la taille du cache d'instructions, la case i du cache ne peut contenir que les instructions placées aux endroits P tels que P i[l]. Ainsi, pour Fig. 1: La boucle génère 2(n + 1) conict-miss éviter les conict-miss, il faut éviter de placer deux chunks souvent appelés en même temps aux mêmes adresses modulo L. L'analyse dynamique consiste à créer une trace à partir d'une exécution sur une entrée donnée et l'exploiter. Le problème de l'analyse dynamique qui, jusqu'à présent, a été l'objet de la plupart des recherches dans le domaine est qu'elle nécessite un jeu de données représentatif ; ceci pose plusieurs problèmes : un tel jeu de données n'est pas évident à choisir pour tous les programmes, et traiter ces données demande de la part de la personne qui compile un eort supplémentaire. Le but de l'analyse statique est donc d'éviter d'avoir à choisir ce jeu de données représentatif qu'il est loin d'être évident de choisir, ainsi que de simplier la vie du developpeur : en eet, avec l'analyse dynamique, le développeur doit prendre une part active dans la phase d'optimisation, tandis que dans le cas statique, les optimisations peuvent avoir lieu de manière totalement transparente. 4

5 4 Etat de l'art 4.1 Call-Graph par Pettis et Hansen [5] A partir d'une trace de programme, c'est à dire la séquence de fonctions par lesquelles il est passé, les auteurs construisent un "call-graph" où les sommets sont les fonctions et les arêtes le nombre d'appels. Seules les procédures les plus utilisées sont conservées dans ce graphe. L'idée de l'algorithme est que deux fonctions proches 1 dans la mémoire auront une place diérente dans le cache, ainsi deux fonctions qui s'appellent souvent seront placées côte à côte dans la mémoire. L'algorithme cherche à maximiser la localité, c'est à dire qu'il cherche à rapprocher dans le placement des fonctions qui sont appelées toutes les deux dans un intervalle de temps court. L'algorithme est glouton, il fusionne itérativement les sommets reliés par une arête de poids maximal en des listes de procédures. Ainsi lors de la fusion de deux sommets A et B (lesquels sont des listes de procédures), il y a quatre possibilités de placement : AB, BA, BA 2 et AB (les autres possibilités sont les listes inversées de celles-ci). Les poids des arêtes sont ensuites sommés dans l'arête fusionnée. 4.2 Temporal Relationship Graph par Gloy et Smith [3] Les auteurs construisent un "Temporal Relationship Graph" (TRG) à partir d'une trace : les procédures sont les n uds et le poids d'une arête entre deux n uds P et Q représente le nombre de fois que deux occurences de la procédure P sont séparées par une occurence de Q dans la trace d'exécution. Ce nombre est le nombre exact de conict-miss qui auraient lieu pour P, si P et Q avaient pour taille une ligne de cache et si elles étaient placées au même endroit. L'algorithme de placement de code construit un graphe de travail à partir du TRG, dans lequel chaque noeud contient une liste de couples dont les premiers éléments sont des procédures et les seconds les décalages relatifs exprimant la position dans le cache de la procédure correspondante par rapport aux autres procédures du n ud. Initialement, chaque n ud contient un seul couple dont la procédure est celle correspondant dans le TRG et dont le décalage est nul. A chaque étape, l'algorithme recherche l'arête de poids maximal et fusionne les noeuds, des permutationset des décalages entres les n uds sont eectués pour trouver le meilleur placement à cette étape. Les positions relatives dénies dans un n ud ne changeront plus de tout l'algorithme : seule la position relative de toutes les procédures d'un n ud par rapport à toutes les procédures d'un autre n ud seront cherchées et modi- 1 Dont la distance est inférieure à la taille du cache 2 Où l'on note A la liste inversée des procédures de A. 5

6 ées à chaque étape. Une fois la fusion eectuée, le décalage des procédures les une par rapport aux autres dans un n ud ne peuvent plus changer. Fig. 2: Illustration de la fusion des ni uds : chaque n ud est ici représenté par un rectangle contenant des procédures (carrés noirs) et leurs décalages relatifs. Ce qui est calculé à la fusion est le décalage entre ces noeuds. 4.3 Minimisation de l'expansion de code de l'algorithme de Gloy et Smith [3] par Bouchez et al. [4] Il s'agit là d'une variante de l'agorithme de Gloy et Smith [3] ayant en plus pour contrainte de minimiser l'expansion de code. Les auteurs utilisent une estimation de l'expansion pour chaque ensemble de procédures an de minimiser celle-ci et de prendre en compte le rapport entre le gain en terme de conits et les pertes au niveau de l'expansion. Une fois le graphe de conit réduit, l'algorithme utilise une méthode optimale pour placer les procédures en conservant les décalages dans le cache. L'expansion de code est bien moins importante que dans l'algorithme de Gloy et Smith [3]. 5 Travail eectué 5.1 Objectifs Le but de ce stage était de construire un graphe de conit de type "Temporal Relationship Graph" à partir d'un graphe de ot de contrôle obtenu par analyse statique ; ceci an de pouvoir ensuite utiliser le TRG obtenu dans l'algorithme de Bouchez et al. [4] 5.2 Notions utiles Basic Bloc Un basic bloc est une portion de procédure s'exécutant insécablement : ainsi un basic block prend n sur un call, une disjonction de cas ou la n de la procédure. 6

7 5.2.2 Chaînes de Markov Une chaîne de Markov est un processus stochastique possédant la propriété Markovienne, c'est à dire que la prédiction du futur ne nécéssite pas d'autre connaissance que celle du présent : le passé n'importe pas. Une chaîne de Markov est représentée par un graphe avec les probas sur les arêtes. On appellera ici chaîne de Markov à pile un ensemble de chaînes de Markov dans lesquelles un état d'une chaîne A peut envoyer au début d'une chaîne B qui une fois l'état nal atteint renverrait à l'état l'ayant appelée dans A. Une chaîne de Markov à pile peut être représentée par un graphe de ot de contrôle Le graphe de ot de contrôle Un graphe de ot de contrôle d'un programme est un graphe dont les sommets sont les basic blocs. Une arête est étiquetée par la probabilité de suivre celle-ci. Ainsi la somme des valuations des arêtes sortant d'un même sommet est toujours 1. Le graphe représentant notre programme est composé de plusieurs sous-graphes de ot de contrôle, un pour chaque procédure. Les appels de procédure sont représentés par des arêtes vertes. La (Fig 3.) donne le graphe de ot de contrôle correspondant aux procédures qui suivent, en commentaires sont marqués les basic blocs correspondant aux instructions : main() début S 0; /* main.1 */ pour i de 1 à 100 faire /* main.3 */ S S + called_fun(i); /* main.2 */ retourner S; /* main.4 */ n called_fun(n) début si n 50 alors /* called_fun.1 */ retourner 40; /* called_fun.2 & called_fun.4 */ n sinon /* called_fun.1 */ retourner n; /* called_fun.3 & called_fun.4 */ 7

8 Fig. 3: Le graphe de ot correspondant au programme précedent : la première case d'un n ud contient son nom, la seconde les instructions qu'il contient et la troisième la procédure qu'il appelle éventuellement Le graphe de destination Le graphe que l'on souhaite obtenir est un graphe du type "Temporal Relationship Graph" an de le passer à l'algorithme de Bouchez et al. [4]. 5.3 Simulation d'exécution Dans un premier temps, on a essayé la solution simple, consistant à parcourir le graphe en eectuant un tirage aléatoire à chaque sommet pour savoir quel successeur on va visiter, tout en simulant 3 un cache associatif de même taille que le cache direct-mapped sur lequel on souhaite travailler. On se sert d'une pile contenant les basic blocks de retour correspondant à chaque appel de fonction : la n de la simulation correspond à arriver à la n d'une fonction alors que la pile est vide. Lorsque l'on a besoin d'un chunk déjà contenu dans le simulateur de cache, on le déplace à la n, en incrémentant les arêtes du TRG de tous les 3 Pour ce faire, on utilise une table de hachage contenant l'adresse en cache du morceau de code. 8

9 chunks contenus entre lui et la n avant le déplacement. Les principaux problèmes posés par cette approche sont que l'on n'est pas sûr que la simulation terminera, de plus celle-ci peut prendre un temps non-négligeable selon la topologie du graphe de ot 4. Cette méthode ne garantit pas l'exploration de tout le graphe de ot et est très dépendante des valeurs aléatoires générées par random : imaginons que le programme ait des options en ligne de commande, l'analyse statique va être incapable de savoir quelles sont celles qui vont être le plus fréquemment utilisés et pourra par exemple mettre une probabilité équivalente pour une option help et work 5 et lors de la simulation, le programme pourrait ne rentrer que dans la branche correspondant au code de l'option help et donc occulter le vrai programme. Nous avons implémenté cette simulation, cependant il nous a été impossible de comparer les résultats obtenus à ceux obtenus par analyse dynamique. Néanmoins, on peut d'ores et déjà armer que cette méthode ne fonctionne pas toujours : ainsi paranoia se simule correctement (de l'ordre de 2-3s pour 1, 1Mo) tandis que l'on peut dire que mp2vloop 6 est trop complexe pour être simulé (une fois sur trois, la simulation ne termine pas et le reste du temps la simulation rentre dans une branche mineure du programme). La (Fig 4.) montre une portion de graphe faisant planter le simulateur ou tout du moins le faisant tourner trop longtemps pour que cela soit intéressant. Fig. 4: La portion de graphe qui fait tourner en rond la simulation sur mp2vloop 5.4 Une simplication du problème An de créer notre TRG, on a besoin de savoir quels sont les chunks qui interfèrent le plus entre eux. Si l'on se restreint aux programmes ne contenant pas de fonctions récursives, on peut insérer les fonctions appelées à l'intérieur du graphe (cf (Fig 5.)). Ce qui permet de n'avoir besoin que de chaînes de Markov et pas de chaînes de Markov à pile, en eet seules les premières ont des propriétés intéressantes connues. On va donc se servir de 4 Par exemple un graphe ayant beaucoup de cycles a de fortes chances de provoquer une simulation longue. 5 Vous comprenez l'idée... 6 ces exécutables nous ont été fournis par STMicroelectronics 9

10 Fig. 5: Le graphe de la (Fig 3.) avant la transformation permettant de se ramener à un graphe correspondant à une chaîne de Markov et après la matrice stochastique associée à notre nouvelle chaîne de Markov 7, notons 7 Pour l'instant, les états de notre chaîne sont des basic blocks et pas des chunks, on passera aux chunks après les exponentiations de matrices pour gagner du temps de calcul. 10

11 la M. On va exponentier successivement M à plusieurs ordres et maintenir en même temps une matrice B telle que : B (l) i,j = l h=1 M h i,j l C'est à dire que la matrice B contient les probabilités d'aller d'un basic bloc i à un basic bloc j en moins de l étapes. L'algorithme va donc calculer les B (l) et M l pour l [1, L], L étant le nombre de lignes de cache total du cache, puis pour chaque couple (P, Q), la probabilité pour qu'une occurence de Q soit contenue entre deux occurences de P est L NP,Q l p (P,Q) = CL l Q,P L l=1 où N l et C (l) sont les matrices d'adjacence construites respectivement à partir de M l et B (l) dont les états sont les chunks et non plus les basic blocs.la transformation consiste en fait à rajouter des matrices diagonales et des 0. Une fois que l'on a calculé cette probabilité, il est facile de contruire un TRG correspondant en multipliant les probabilités obtenues par une constante, car l'on sait que l'algorithme qui tournera dessus par la suite est de type glouton sur la valeur des arêtes. La complexité de ces opérations est O(L K 3 ) où L est le nombre de lignes du cache et K le nombre de basic blocks. Par manque de temps, cet algorithme n'a pas été implémenté, néanmoins nous sommes en mesure d'armer que la complexité ne permettrait pas une exécution rapide de l'algorithme sur un programme de taille habituelle, tel que mp2vloop ou paranoia, ceux-ci ayant un nombre de basic bloc très élevé. 6 Conclusions Nous avons implémenté un simulateur qui permet d'obtenir des résultats sur certains graphes, ne contenant pas de boucles imbriquées dont la probabilité de sortir est trop petite 8. Nous avons également trouvé une solution qui fonctionnerait 9 sur une certaine restriction de programmes : les programmes non récursifs ; ceci avec une complexité de l'ordre de O(L n 3 ) où n est le nombre de basic blocs, néanmoins nous pouvons espérer réduire cette complexité car la matrice d'adjacence du graphe de ôt de contrôle contient beaucoup de 0. 8 Typiquement sur les graphes que nous avons testés, cette probabilité est de l'ordre de ou moindre. 9 L'implémentation pourrait cependant s'avérer dicile à cause des limites des ottants. 11

12 7 Remerciements Je tiens particulièrement à remercier mes maîtres de stage : Benoit et Fabrice, qui tout au long de mon stage m'ont apporté aide et soutien tout en me laissent beaucoup de liberté dans les axes à explorer. Ils m'ont de plus laissé du temps pour préparer le concours d'entrée en même temps que mon stage, et je les en remercie : sans leur soutien je n'y serais probablement pas parvenu. Je tiens également à remercier tous les autres, qui m'ont apporté leur aide à un moment ou à un autre pendant ce stage : Damien Pous, Florent Bouchez, Eric Thierry, Sebastian Hack, Bruno Grenet et Nicolas Estibals. Références [1] A. W. Appel. Modern Compiler Implementation in ML. Cambridge University Press, [2] Pierre Bremaud. Markov Chains. Springer, January [3] Nikolas Gloy and Michael D. Smith. Procedure placement using temporal-ordering information. ACM Transactions on Programming Languages and Systems, 21(5) : , [4] Christophe Guillon, Fabrice Rastello, Thierry Bidault, and Florent Bouchez. Procedure placement using temporal-ordering information : dealing with code size expansion. Journal of Embedded Computing, 1(4) : , [5] Karl Pettis, Robert C. Hansen, and Jack W. Davidson. Prole guided code positioning. SIGPLAN Not., 39(4) :398411,