Construction d'une hiérarchie mémoire faible consommation Daniel CHILLET, David SAILLE, Olivier SENTIEYS Equipe R2D2 – IRISA / ENSSAT Université de Rennes 1 6, rue de kérampont 22300 LANNION chillet@enssat.fr http://www.irisa.fr/R2D2

Plan Introduction et motivations Méthodologie développée Résultats Conclusions et perspectives

Introduction et motivations Evolution des applications Puissances de calcul importante Capacités de stockage important Volume de données : environ + 30% / an Systèmes sur puces Blocs IP Mémoires La part (en terme de surface) monopolisée par la partie mémoire est importante, elle représente dans certains système plus de la moitie de le surface utile du chip. Ici on voit le die du processeur Itanium 2 (c'est un processeur d'usage générale mais il est tout de même représentatif de ce qui se passe pour une grande majorité de chip). La surface de la mémoire représente ici entre 60 et 70% de la surface.

Introduction et motivations Bilan énergétique e.g. codage d’image H263 [Catthoor98] 1500K opérations et 500K accès mémoire Energie transferts = 33.Energie opérations Energie totale mémoire # 10.Energie totale opérations Add Mult RAM Read Write I/O Memory Transfer (Off-Chip) Energie / opération 33 10 9 Cette surface s'accompagne bien évidemment d'une activité non négligeable. Le volume des données manipulées par les applications croit de façon importante environ 30 % par an On voit ici la répartition de la consommation dans un circuit pour une application donnée. on voit très nettement que la part de consommation due a la mémoire est très importante. En bas à droite, la répartition de la consommation dans un circuit ciblant une application télécommunication. On voit ici aussi, que la partie mémorisation prend une importance non négligeable d'un point de vue consommation. 4.4 3.6 1

Etat de l’art : hiérarchisation mémoire Hiérarchie mémoire fixée Placement des données les plus souvent utilisées dans des mémoires internes [Kol96][Wuy94] Optimisations par minimisation de la taille mémoire [Dig97] Mémoires caches [Abr99][Su95] Scratch-pads [Panda99] Ordonnancements [Sa96] Optimisation conjointe hiérarchie-placement [Catthoor98] Les principaux objectifs poursuivit lorsque l'on met en place une hiérarchie mémoire sont : d'optimiser le placement des données dans la hiérarchie afin de limiter les transferts et donc la consommation - limiter aussi les tailles des mémoires par réutilisation des points mémoires (limite la consommation statique)

Approche proposée Modèle mémoire SRAM interne [FTFC2001] Placement des données et construction de la hiérarchie Spécialisation à une application Plusieurs niveaux de hiérarchie

Plan Introduction Méthodologie développée Résultats Conclusions et perspectives

Principes Exploitation du déterminisme de l'application Nombre, dates, sens des accès aux données Exploitation du profil des accès aux données Localité spatiale ou temporelle des transferts de données Temps Adresses Localité temporelle Localité spatiale La méthodologie que nous avons développée s'appuie sur une analyse des accès réalisés par l'application. On tente d'exploiter le déterminisme de l'application et d'exploiter le fait que l'on connaît exactement les dates d'utilisation des données de l'algorithme. Sur le schéma, on illustre les notions de localité qui sont la base de l'augmentation de performances dans les systèmes hiérarchique de mémoires.

Modèle architectural Construction d'une solution mémoire hiérarchique Détermination du nombre de niveaux Type et nombre de transferts principale Mémoire Partie opérative Pseudo cache niveau 1 Pseudo cache niveau 2 La solution architecturale que nous recherchons est basée sur une hiérarchie mémoire à plusieurs niveaux. L'objectif de notre proposition consiste à définir le nombre de niveaux de mémoire à mettre en place ainsi qu'à définir la position des données à chaque instant (donc à définir les transferts entre les niveaux mémoires). Registres

Méthodologie développée Point d'entrée de la méthodologie Liste des accès aux données d0 d1 d2 d3 d4 Lecture mémoire Ecriture mémoire Temps Données La méthode que nous avons développée travaille sur une liste d'accès directement issue de l'exécution de l'application. La liste des accès peut être représentée par un graphe de ce type qui indique pour chaque cycle de l'algorithme quels transferts doivent être réalisés entre la mémoire et la partie opérative.

Méthodologie développée Compilation + exécution Compilation (Suif) Code C Code C annoté Liste des accès aux données Graphe de dépendances Bibliothèque de mémoires Modèle architectural à 2 niveaux Consommation Estimation Voici une vue assez globale du flot d'estimation de la mémoire que nous avons mis en place. Ce flot prend en entrée une application décrite en C. Cette application est tout d'abord analysée afin de repérer l'ensemble des accès mémoire réalisé par l'algorithme. Le code C est ensuite annoté puis compilé et exécuté afin d'obtenir la liste temporelle des accès réalisé. Cette liste des accès est décrite de telle façon a ce que l'ordre des opérations de lecture et d'écriture soit clairement précisé. Le modèle sur lequel s'appuie le placement des données est constitué de 2 niveaux mémoires uniquement. Nous verrons que la construction d'une hiérarchie à plus de niveau s'effectue par réitération de la méthode. Placement des données dans une hiérarchie à deux niveaux Calcul des fréquences d'utilisation, tri des données

Méthodologie développée Placement dépend du type de la donnée Constante : peut être placée uniquement en pseudo cache Entrée / sortie : doit être stockée en mémoire principale, c'est la seule mémoire en liaison avec l'extérieur Temporaire de calcul : peut être stockée uniquement en pseudo cache Le placement des données dans la hiérarchie mémoire ne peut se faire de façon complètement libre. En effet, certains types de données possèdent des contraintes spécifiques qui les rendent incompatible avec un stockage dans un niveau mémoire. C'est le cas par exemple des données de type entrée sortie. Le modèle architectural que nous avons définit ne permet pas de proposer une connexion extérieure avec un autre niveau mémoire que le niveau le plus haut. Aussi une donnée de type entrée sortie doit forcement être stockée dans cette mémoire.

Méthodologie développée Evaluation de l'intérêt du placement d'une donnée en pseudo cache Placement de Di dans la mémoire principale Conso(Di) = NbAcces(Di).Conso(AccesMemPrincipale) Placement de Di dans le pseudo cache si Di est une constante Conso(Di) = NbAcces(Di).Conso(AccesPseudoCache) si Di est une variable temporaire de calcul si Di est une entrée/sortie Conso(Di) = Conso(AccesMemPrincipale) + NbAcces(Di).Conso(AccesPseudoCache) Le placement d'une donnée dans un niveau mémoire peut engendrer des accès supplémentaires (entre les niveaux de mémoire). C'est le cas par exemple d'une donnée de type entrée que l'on choisirait de stocker temporairement dans un niveau mémoire autre que la mémoire principale (à cause d'une utilisation intensive durant une période de l'algorithme). Dans ce cas, la donnée doit d'abord être transférée depuis la mémoire de plus haut niveau vers la mémoire cache. Dans le cas ou la donnée est une constante, il est possible de stocker ladite donnée uniquement dans la mémoire rapide (cache), dans ce cas la consommation associée aux accès à cette donnée est lié à la consommation de cette mémoire.

Méthodologie développée Placement des données optimal Consommation globale = S Conso(Di)  i  {1 … D} avec D le nombre de données Heuristique Parcours du graphe depuis les données ayant les fréquences d'accès les plus élevées Arrêt de la recherche lorsque le placement d’une donnée en cache n’offre pas de gain La consommation globale du système est donc la somme des consommations des accès de toutes les données. Il est claire que la recherche de la solution optimale rend le problème impossible à résoudre en un temps raisonnable surtout lorsque l'application manipule un volume de données très important. Nous avons alors développé un algorithme glouton qui exploite les fréquences d'accès aux données. En effet, il est claire que plus une donnée à une fréquence d'accès (ou d'utilisation) importante, plus elle a intérêt à être stockée en mémoire cache. Donc notre algorithme va tenter le placement des données dans la mémoire cache en parcourant l'ensemble de ces données depuis les données les plus utilisées jusqu'aux données les moins utilisées. Dès lors qu'une donnée n'offrira pas un gain en consommation,alors l'algorithme sera stoppé.

Méthodologie développée Evaluation d'un second niveau de cache Transferts entre pseudo cache et partie opérative Réitération de la méthode Partie opérative principale Mémoire Pseudo cache niveau 1 Une fois avoir définit une structure hiérarchique à deux niveaux de mémoires, on s'intéresse aux transferts réalisés entre la partie opérative et la mémoire cache. L'évaluation d'un second niveau de mémoire cache est donc réalisé sur cet ensemble d'accès et une seconde passe de la méthode est réalisée afin d'évaluer l'intérêt d'une mémoire cache de taille plus faible entre la partie opérative et la mémoire cache précédemment définie. Registres

Plan Introduction Méthodologie développée Résultats Conclusions et perspectives

Résultats Application : produit de matrices Réutilisation de données Chaque élément des matrices A et B est réutilisé N fois for (i = 0 ; i < N ; i++) { for (j = 0 ; j < N ; j++) { C[i][j] = 0; for (k = 0 ; k < N ; k++) { C[i][j] = C[i][j] + A[i][k] * B[k][j]; } Les résultats que nous donnons ici concerne une application dont le taux de réutilisation des données est assez élevé. Il s'agit du produit de matrices (sans aucune optimisation). Cette écriture du produit de matrices fait apparaître un taux de réutilisation des éléments des matrices A et B égal à N (N étant la taille des matrices à multiplier)

Résultats Illustration de la réutilisation des données Mémoire A B C Adresses On illustre ici la séquence des accès qui va être réalisée par la partie opérative (on suppose ici évidemment que la partie opérative respectera cet ordre dans les accès aux données). On voit très clairement apparaître les notions de localité sur les accès aux données. En effet, pour un produit de matrices 3*3, on observe que chaque élément de la matrice A est utilisé 3 fois, il en est de même pour l'ensemble des éléments des matrices A et B. Pour la matrice C, il n'existe pas de réutilisation des éléments. Ce simple schéma permet de savoir très rapidement si il existe de la localité spatiale et temporelles dans les accès aux données. Ici clairement il existe de la localité, donc la mise en place d'une hiérarchie peut s'avérer intéressante. Temps

Résultats Graphe de dépendances B[0][0] A[0][1] B[1][0] A[0][2] B[2][0] C[0][1] A[0][0] B[0][1] A[0][1] B[1][0] A[0][2] B[2][1] Cette liste de dépendances est modélisable par un graphe de donnée dont les nœuds représentent les données de l'algorithme et les arcs les dépendances entre ces données. C[0][2] A[0][0] B[0][2] A[0][1] B[1][2] A[0][2] B[2][2]

Résultats Placement des données et dimensionnent Parcourt de l'ensemble des données Des données les plus utilisées, Eléments des matrice A et B (N utilisations) aux données les moins utilisées. Eléments de la matrice C (1 seule utilisation) Dimensionnement des mémoires : pseudo cache, principale. L'algorithme glouton de placement est ensuite appliqué sur l'ensemble des données préalablement trié par ordre décroissant des fréquences d'accès.

Taille mémoire pseudo-cache Résultats Technologie 0.18u Compilateur Artisan Taille matrices Taille mémoire principale Taille mémoire pseudo-cache Gain 10*10 300 0 % 16*16 768 16 10,8 % 20*20 1200 24 22,1 % 30*30 2700 64 40,3 % Matrice C c0,0 c0,1 … c30,30 Matrice B b0,0 b0,1 b30,30 Matrice A a0,0 a0,1 a30,30 Matrice C c0,0 c0,1 … c29,29 Matrice B b0,0 b0,1 b29,29 Matrice A a0,0 a0,1 a29,29 Pseudo cache (64) 54000 1800 Partie opérative 54900 transferts 0,2 uJ Partie opérative 1,9 uJ Voici quelques résultats concernant la définition d'une structure hiérarchique de mémoire. Ici nous avons représenté les solutions sans et avec hiérarchie mémoire. La solution sans hiérarchie mémoire engendre une consommation (des accès mémoires) égale à 3,6 micro Joule alors que la solution avec hiérarchie mémoire engendre une consommation égale à 2,6 micro Joule. Le gain est alors d'environ 40 % sur la partie mémoire. Registres Registres 3,6 uJ Total = 2,16 uJ 900 0,06 uJ Sans hiérarchie mémoire Avec hiérarchie mémoire

Résultats Réutilisation des points mémoires dans le pseudo cache Matrice C c0,0 c0,1 … c29,29 Matrice B b0,0 b0,1 b29,29 Matrice A a0,0 a0,1 a29,29 a0,0 ; a1,0 ; a2,0 ; a3,0 ; a4,0 ; …………… a29,0 a0,1 ; a1,1 ; a2,1 ; a3,1 ; a4,1 ; …………… a29,1 a0,2 ; a1,2 ; a2,2 ; a3,2 ; a4,2 ; …………… a29,2 a0,3 ; a1,3 ; a2,3 ; a3,3 ; a4,3 ; …………… a29,3 ………………………………………..................... ……………………………………………………. b0,0 ; b0,1 ; b0,2 ; b0,3 ; b0,4 ; …………… b0,29 b1,0 ; b1,1 ; b1,2 ; b1,3 ; b1,4 ; …………… b1,29 b2,0 ; b2,1 ; b2,2 ; b2,3 ; b2,4 ; …………… b2,29 Registres opérative Partie Ici nous avons représenté la position des différentes données dans la mémoire cache. Compte tenu des durées de vie des éléments des matrices A et B, la solution qui nous est proposée indique que tous les éléments d'une colonne de A peuvent être stockés dans la même case mémoire (ils ont des durées de vie disjointes).

Conclusions Proposition d'une méthode pour définir une hiérarchie mémoire Evaluation de la consommation mémoire d'une application écrite en langage C Méthode indépendante des outils de conception Construction de la hiérarchie La conception des autres blocs du SOC doit prendre en compte le placement des données

Perspectives Optimisation multicritères Performances/Energie/Surface Extension de la méthode aux mémoires partagées dans un SOC Accès concurrents de différentes unités Partage de données Gestion de la cohérence des données Extension de la méthode pour l'accès aux programmes et aux configurations Programmes d'unité(s) programmable(s) Configurations d'unité(s) reconfigurable(s)

Méthodologie développée Soit  l'ensemble de données triées par ordre décroissant des fréquences d'accès TailleMem = Cardinalite (); TailleCache = 0; NbAccesMemOp = NbAcces(di pour toute di   ) ; NbAccesCacheOp = NbAccesMemCache = 0; consoOptimalCourante = NbAccesMemOp * consoAcces (TailleMem ) ; Pour toute donnée di   faire si di est constante ou di est temporaire alors NbAccesMemOp -= NbAcces (di) ; NbAccesCacheOp += NbAcces (di) ; si (Cache ne peut pas contenir di) alors TailleCache ++; TailleMem --; fsi; si di est input alors NbAccesMemCache += 1 ; NbAccesCacheOp += NbAcces (di) ; conso = (NbAccesMemOp + NbAccesMemCache ) * consoAcces (TailleMem ) + (NbAccesMemCache + NbAccesCacheOp ) * consoAcces (TailleCache ) ; si conso > consoOptimalCourante alors fin; faire;

Introduction - motivations Organisation mémoire : d'un point de vue consommation Consommation Ici est représente une hiérarchie classique de mémoire en partant des éléments de stockage les plus proches des unités de calcul (les registres) et en allant vers les plus éloigné (les unités de sauvegarde) D'un point de vue consommation, il est clair que l'accès a de petites mémoires est plus intéressant. Aussi la structure en hiérarchie mémoire peut être exploitée pour minimiser la consommation de système. Cette organisation n'est pas contradictoire avec les performances du système puisque la structure en hiérarchie a été développée pour augmenter ces performances.

Introduction - motivations Hiérarchisation mémoire : Constats et motivations : croissance importante du coût engendré par la mémorisation la mémoire est très souvent le goulot d'étranglement du système Modèle sans hiérarchisation : mal adapté, beaucoup d'accès à une grosse mémoire nécessite de disposer de mémoires importantes et avec temps d'accès court L'évolution des systèmes de stockage a donné naissance a des organisations mémoire hiérarchique. Le but étant de mettre en place une organisation pour laquelle on exploite les localités spatiales et temporelles des accès d'un processeur pour lui assurer un maximum d'accès réussit dans une mémoire rapide mais de faible de taille.

Méthodologie développée Modèle fonctionnel : transferts possibles : pseudo cache partie opérative mémoire principale partie opérative mémoire principale pseudo cache Modèle temporel : parallélisme possible : jusqu'à 3 transferts possibles en // : 1 transfert partie opérative ou pseudo cache 1 transfert partie opérative ou mémoire principale 1 transfert pseudo cache ou mémoire principale 1 donnée 1 donnée N données

Résultats Code annoté par Suif : for (i = 0 ; i < N ; i++) { for (j = 0 ; j < N ; j++) { C[i][j] = 0; write (&C[i][j] ); for (k = 0 ; k < N ; k++) { C[i][j] = C[i][j] + A[i][k] * B[k][j]; read (&C[i][j] ); read (&A[i][k] ); read (&B[k][j] ); } Voici ici le code de l'application après analyse et annotation par le front end de compilation Suif. L'analyse détecte l'ensemble des accès mémoire et ajoute du code pour chacun d'eux . Le code ajouté est un simple appel de procédure. Ensuite le code annoté est compilé, puis une édition des liens avec le code des procédures est faite. Dans notre cas, les procédures se contentent d'indiquer, dans un fichier et sous une forme particulière, l'ensemble des accès réalisé.

Résultats Exécution et obtention de la liste des accès % Declaration de dependances C[0][0] 0 C[0][0] 3 C[0][0] A[0][0] B[0][0] C[0][0] 3 C[0][0] A[0][1] B[1][0] C[0][0] 3 C[0][0] A[0][2] B[2][0] C[0][1] 0 C[0][1] 3 C[0][1] A[0][0] B[0][1] C[0][1] 3 C[0][1] A[0][1] B[1][1] C[0][1] 3 C[0][1] A[0][2] B[2][1] C[0][2] 0 C[0][2] 3 C[0][2] A[0][0] B[0][2] C[0][2] 3 C[0][2] A[0][1] B[1][2] C[0][2] 3 C[0][2] A[0][2] B[2][2] … C[0][0] = C[0][0] + A[0][0] * B[0][0] Voici ici la liste des accès que l'on obtient une fois l'exécution du code annoté réalisé. Le fichier contient une ligne pour chaque écriture de donnée réalisée dans le code. De plus, pour chaque écriture d'une donnée, on indique le nombre de donnée dont dépend cette écriture ainsi que les données sources. Sur l'exemple de code exécuté qui est donnée en haut à droite, on voit qu'effectivement, l'écriture de la donnée C[0][0] est dépendante des opérations de lecture des données sources que sont C[0][0], A[0][0] et B[0][0].