Architecture & bits significatifs

Présentation au sujet: "Architecture & bits significatifs"— Transcription de la présentation:

1 Architecture & bits significatifs
Thèse de doctorat Olivier Rochecouste sous la direction d’André Seznec Projet CAPS / IRISA Lundi 24 Octobre 2005

2 Surdimensionnement de la microarchitecture ?
Problématique Évolution de la taille des mots traités par le processeur : Intel (1971) : 4-bit Intel Itanium (2000) : 64-bit Usage restreint des données 64-bit dans les applications : applications multimédia (audio/vidéo 8-/16-bit) 50% des données entières sont sur 16-bit à l’exécution [Brooks’99] Surdimensionnement de la microarchitecture ? Impacts sur la consommation, la surface de silicium et la fréquence du processeur

3 État de l’art Exploiter le format des données
Améliorer les performances : parallélisme de données (SIMD*) [Nakra’00, Loh’02] Optimiser la consommation d’énergie : matériel reconfigurable [Brooks’99, Canal’00] 64-bit 64-bit 16-bit 16-bit + + + + + 64-bit 64-bit 16-bit 16-bit + + *Single-Instruction Multiple-Data

4 État de l’art Identifier le format des données
uint32 x = 0; uint16 i = 0; for (i = 0; i < 25; i++) { x += i; ... } uint16 x = 0; /* 8-bit : 88%, 16-bit : 12% */ Approche dynamique [Brooks’99, Choi’00] détection cycle par cycle repose sur un mécanisme matériel Approche « compilateur » [Stephenson’00, Budiu’00] analyse du flot de données doit préserver la sémantique du programme

5 Contributions de la thèse
Exploiter le format des données pour réduire la complexité du processeur Première contribution : technique matérielle / logicielle de redimensionnement du chemin de données contexte embarqué Seconde contribution : traitement découplé des opérations tronquées (16-bit) sur des opérateurs dédiés contexte hautes performances

6 Technique matérielle / logicielle de redimensionnement du chemin de données

7 Motivations 60% de données entières 16-bit à l’exécution
Distribution du format des données dynamiques [Powerstone] 60% de données entières 16-bit à l’exécution opportunité pour réduire la consommation d’énergie redimensionner le chemin de données

8 renforcer le compilateur avec une connaissance dynamique : profiling
Notre approche Approche dynamique Approche compilateur éviter le recours à un support matériel pour identifier le format des données : complexe s’appuyer sur le compilateur pour identifier le format des données : adéquate renforcer le compilateur avec une connaissance dynamique : profiling éviter le recours à une analyse statique pour optimiser la taille des données : restrictive Spéculer sur la taille des données par logiciel pour redimensionner le chemin de données

9 + Support matériel (1) Chemin de données redimensionnable [Brooks’99]
mode d’exécution 8,16 ou 32-bit : « clock-gating » Fichier de registres en tranches : « nouvelle approche » mode 8, 16 ou 32-bit : « drowsy mode » [Flautner’02] données préservées « tag bits » : dimension effective des données mise à jour des tag bits column decoder + 11 - 10 tag bits 01 16-bit mode 32-bit mode 8-bit mode 16-bit

10 Support matériel (2) Instruction de reconfiguration :
changer le mode d’exécution Mécanisme de recouvrement : Identifier : comparer le mode d’exécution à la largeur des opérandes (tag bits) Corriger : vider le pipeline redimensionner le chemin de données rejouer les instructions

11 Spéculation du format des données par logiciel
Redimensionnement du chemin de données granularité utilisée : bloc de base (ou région) Identifier le format d’exécution des blocs de base : prédire sur la base des données du profiling fonction du taux d’utilisation en données 16-bit (> 80%) Insérer les instructions de reconfiguration : formation de régions add r1, r2  r3 … mode 16 xor r2, r3  r4 mode 32 instructions de reconfiguration région 16-bit

12 Environnement expérimental
Benchmarks : 14 applications Powerstone [M.core] Configuration simulée : architecture VLIW 4 x 32-bit 64 registres généraux 32-bit 4 ALUs, 1 unité load/store Estimer la consommation d’énergie (analytique) : ALU : énergie(32-bit) ~ 2 x énergie(16-bit) fichier de registres : CACTI : énergie dynamique par accès Hotleakage : énergie statique par accès

13 Évaluation expérimentale
Consommation d’énergie : chemin de données : gains en dynamique : 17% fichier de registres : gains en statique : 22% Performances : Pénalité de recouvrement 5 cycles pénalité : - 2% 25 cycles pénalité : - 5% consommation performances

14 Récapitulatif Technique matérielle / logicielle de redimensionnement du chemin de données Spéculation par logiciel du format d’exécution des blocs de base Support matériel : mécanisme de recouvrement chemin de données et fichier de registres 8/16/32-bit Réduction de la consommation d’énergie : chemin de données (dynamique) : 17% fichier de registres (statique) : 22%

15 Comment adapter l’approche pour un modèle à exécution dans le désordre ?
exécution atomique des régions inadéquation d’une approche par profiling

16 Traitement découplé des opérations tronquées sur des opérateurs dédiés
Le modèle à clusters WPM « Width-Partitioned Microarchitecture »

17 Le modèle à clusters partitionner les ressources de calcul entre différents groupes (clusters) pour réduire la complexité du processeur Nécessite : mécanisme pour distribuer le programme sur les clusters mécanisme pour communiquer les données entre les clusters fetch decode ressources centralisées rename dispatch issue issue execute execute cluster write-back write-back commit

18 Découpler sur des opérateurs dédiés :
Motivations Mediabench SPEC2000 100% FFF 80% FFN 60% NFF NFN 40% NNF 20% NNN 0% cjpeg epic ghostscript bzip2 gcc mcf average Caractérisation du format des opérations dynamiques Notation : N : narrow-width (16-bit) F : full-width (64-bit) [16, 16  64]  NNF 40% en opérations NNN Découpler sur des opérateurs dédiés : le modèle WPM

19 Modèle WPM découpler FFF NNN FFF NNN FFF NNN cluster 16-bit
fetch decode fetch decode NNN rename dispatch rename dispatch issue issue issue issue découpler execute 64-bit execute execute 16-bit execute cluster 16-bit write-back write-back write-back write back commit commit Modèle à clusters classique 64-bit Modèle WPM

20 Modèle WPM Implémentation basique
cluster 64-bit cluster 16-bit Communications inter-cluster : duplicata RF 16-bit réduire la complexité du RF 64-bit ALUs 16-bit reliées au duplicata Load/store reliée au 16-bit RF 64-bit RF 64-bit RF duplicata 16-bit RF 16-bit RF bypass bypass 64-bit ALU load/store + ALU 16-bit ALU 16-bit ALU cache de données

21 Modèle WPM Implémentation optimisée
cluster 64-bit cluster 16-bit Pour optimiser la connexité opérations FFN et FNN : 3%  opportunités Mise à jour à la demande : instruction de copie générée par le matériel Duplicata 16-bit : ports écriture / 2 64-bit RF duplicata 16-bit RF 16-bit RF 1 bypass bypass 2 64-bit ALU load/store + ALU 16-bit ALU 16-bit ALU 3 3 1 2 cache de données

22 Distribution des instructions
Basée sur un prédicteur de largeur exposer les opérations NNN Mauvaises prédictions : « effectives » : largeur prédite < largeur produite « conservatrices » : largeur prédite > largeur produite Schéma bimodal avec compteur RAZ prédit 16-bit quand saturé sinon 64-bit remis à zéro quand 64-bit 1 x 16-bit 64-bit prédit 64-bit prédit 16-bit

23 Mécanisme de recouvrement
Détection des mauvaises prédictions à l’étage d’exécution : logique de détection des zéros [Brooks’99] Correction : mauvaises prédictions effectives vider pipeline rejouer instructions sur le cluster 64-bit mettre à jour tables de prédiction Correction : mauvaises prédictions conservatrices

24 Environnement expérimental
Benchmarks : 7 Mediabench et 7 SPEC2000 Modèles simulés : WPM basique, WPM optimisé 80 registres par RF prédicteur de largeur bimodal avec 4096 compteurs RAZ 3-bit MP effective < 0.1% Estimation de la consommation d’énergie (analytique) : ALU : énergie(64-bit) ~ 4 x énergie(16-bit) fichier de registres : CACTI interconnexions : énergie(16-bit) ~ 0.84 énergie(64-bit) [Bala’05]

25 Modèle de référence Cluster 0 : Cluster 1 :
fetch decode Cluster 0 : 1 ALU 64-bit / 1 load/store Cluster 1 : 2 ALUs 64-bit 1 copie RF 64-bit / cluster mise à jour systématique délai inter-cluster Distribution des instructions [Canal’00] minimiser communications inter-cluster préserver l’équilibrage des charges rename dispatch cluster 0 cluster 1 issue issue execute 64-bit execute write-back write-back commit

26 Complexité du fichier de registres
Surface de silicium : analytique [Zyuban’98] Temps d’accès et énergie par accès : CACTI [Jouppi’00] référence WPM basique WPM optimisé position du cluster 1 largeur du registre (bits) 64 64/16 16 # registres 80 80/80 ports d’accès (lecture/écriture) (4,4) (4,2) / (2/4) (4,3) (4,2) / (2/2) réduction de la surface - 34% 81% 43% réduction du temps d’accès 6% / 16% 15% 6% / 22% réduction énergie 21% / 63% 35% 21% / 71%

27 Réseau d’interconnexion
Interconnexions inter-cluster (16-bit) : surface de silicium / 4 consommation d’énergie - 20% Interconnexions hétérogènes [Bala’05]  (largeur & espacement) =  délai espacement longueur largeur hauteur interconnexions classiques optimisées pour le délai

28 Consommation d’énergie
ALU RF interconnexions 100% 100% 80% 80% WPM basique 60% 60% WPM optimisé 40% 40% 20% 20% consommation d’énergie 0% 0% cjpeg djpeg epic bzip2 gcc gzip avg. WPM basique ALU : 20 % RF : 50% interconnexions : 60% WPM optimisé : ALU : 13% RF : 50% interconnexions : 80%

29 Performances Oracle : prédicteur de largeur parfait
25% 25% WPM basique + oracle WPM basique + bimodal 15% 15% WPM optimisé + bimodal 5% 5% WPM basique + int. hétér. WPM optimisé + int. hétér. -5% -5% -15% -15% performances -25% -25% cjpeg djpeg epic bzip2 gcc gzip avg. Oracle : prédicteur de largeur parfait Bimodal : prédicteur bimodal 3-bit 4096 entrées Interconnexions hétérogènes : délai / 2 [Bala’05]

30 Modèle WPM Récapitulatif
Modèle WPM « Width-Partitioned Microarchitecture » : découpler le traitement des opérations NNN pour réduire la complexité du processeur aucun mécanisme matériel nécessaire pour redimensionner gains en énergie : fichier de registres : 50% interconnexions inter-cluster : 60 à 80% dégradation des performances : 7%

31 Conclusion générale Surdimensionnement du chemin de données
Exploiter le format des données pour réduire la complexité Deux contributions : technique matérielle / logicielle pour redimensionner le chemin de données systèmes embarqués traitement découplé des opérations tronquées sur des opérateurs dédiés (modèle WPM) systèmes hautes performances

32 Directions futures Appliquer le modèle WPM au contexte VLIW :
motivations : modèle à clusters populaire utiliser le compilateur pour distribuer les opérations Examiner le passage à l’échelle du modèle WPM : comment le modèle WPM peut être adapté pour supporter un degré d’exécution et un nombre de clusters plus importants ?

33 Merci de votre attention.
Questions ?

34 Backup slides

35 Sources de consommation
2 sources principales dans la technologie CMOS* : consommation dynamique 90% avec géométrie > 0.13µ consommation statique 50% avec géométrie < 0.09µ Consommation dynamique Pdynamique = a . (CL * Vdd2 * f) Consommation statique Pstatique = Vdd * Ifuite Ifuite = Iox + Isub + Idiode *Complementary Metal Oxyde Silicon

36 Technique matérielle/logicielle Optimisations logicielles

37 Benchmarks Applications Description adpcm voice encoding/decoding auto
automotive control code bcnt bitcount bffo find first zero bilv shift, and, or operations brev bit reverse operations compress data compression des data encryption engine engine control application fir integer FIR filter g721 protocol for voice transmission pocsag communication protocol for paging qurt root computation of quadratic equations v42bis modem encoding/decoding Applications Description epic image compression M E D I A B N C H g721 voice compression ghostscript postscript interpreter jpeg mesa 3D graphics library mpeg2 video compression pegwit encryption algorithm bzip2 data compression S P 2 gcc C compiler gzip mcf combinatorial optimization parser word processing vortex database vpr FPGA place route

38 Modèle WPM équilibrage des charges
Métrique : différence du nombre d’opérations prêtes à s’exécuter dans chaque cluster à chaque cycle [Canal’00] équilibrage parfait : différence = 0 équilibrage correct : différence < 5 Résultats : équilibrage correct [0-2] : 50% exécution équilibrage

39 Modèle WPM analyse de la complexité (3)
Réseau de bypass : modèle de référence : 5 sources par cluster WPM basique : 6 sources (cluster 64-bit) – 4 sources (cluster 16-bit) WPM optimisé : 5 sources (cluster 64-bit) – 4 sources (cluster 16-bit) Logique de réveil : 4 sources par cluster 4 sources (cluster 64-bit) – 3 sources (cluster 16-bit) 3 sources par cluster

40 Modèle WPM Distribution des instructions (2)
Heuristique : Soit i, l’instruction à assigner : Tous les opérandes sources de i appartiennent au RF16 : Si résultat prédit 16-bit alors i assignée au cluster 16 Sinon i assignée au cluster 64 Au moins un opérande source de i appartient au RF64 : i assignée au cluster 64 Si résultat prédit 16-bit alors résultat écrit dans RF16 Sinon résultat écrit dans RF64

41 Modèle WPM analyse de la complexité (1)
Fichier de registres : surface de silicium [Zyuban’98] : Nregs : nombre de registres Wregs : largeur du registre en bits Nread : nombre de ports d’accès en lecture Nwrite : nombre de ports d’accès en écriture w : largeur des interconnexions temps d’accès et consommation : CACTI Nregs x Wregs x w² x (Nread+ Nwrite) x (Nread+ 2 x Nwrite)

42 Modèle WPM analyse de la complexité (2)
Conventionnel WPM basique WPM optimisé numéro du cluster 1 # RF 2 largeur de registre (bits) 64 64/16 16 # registres 80 80/80 ports lecture/écriture (4,4) (4,2) / (2/4) (4,3) (4,2) / (2/2) surface de silicium 491520 89600 réduction de la surface - 34% 81% 43% temps d’accès (TA) 0.6326 / 0.5342 / réduction du TA 6% / 16% 15% 6% / 22% énergie nJ/accès 0.5431 / 0.3500 / réduction énergie 21% / 63% 35% 21% / 71%