Architecture & bits significatifs

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

2. Problématique • Évolution de la taille des mots traités par le processeur : • Intel 4004 (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’artExploiter 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’artIdentifier le format des données • 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 uint16 i = 0; for (i = 0; i < 25; i++) { x += i; ... } uint32 x = 0; uint16 x = 0; /* 8-bit : 88%, 16-bit : 12% */

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 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. 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 éviter le recours à une analyse statique pour optimiser la taille des données : restrictive renforcer le compilateur avec une connaissance dynamique : profiling 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 1100110001011101 01011101 00110000 11 10 01011101 - 11001100 01 tag bits 11001100 32-bit mode 16-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 cluster execute execute write-back write-back commit

18. 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. FFF FFF NNN NNN découpler Modèle WPM FFF fetch decode fetch decode NNN rename dispatch rename dispatch issue issue issue issue 16-bit execute execute cluster 16-bit 64-bit execute execute write-back write back write-back write-back commit commit Modèle WPM Modèle à clusters classique 64-bit

20. Modèle WPMImplémentation basique cluster64-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 16-bit RF 64-bit RF 64-bit RF duplicata 16-bit RF bypass bypass 16-bit ALU 64-bit ALU load/store + ALU 16-bit ALU cache de données

21. Modèle WPMImplé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 16-bit RF 64-bit RF duplicata 16-bit RF 1 bypass bypass 2 16-bit ALU 64-bit ALU load/store + ALU 16-bit ALU 3 3 1 2 cache de données

22. 64-bit x 0 1 16-bit 16-bit 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 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 • mettre à jour tables de prédiction

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 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 64-bit execute 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]

27. longueur largeur hauteur espacement 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 interconnexions classiques optimisées pour le délai

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

29. Performances • 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] 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.

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/logicielleOptimisations logicielles

37. Benchmarks

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 WPManalyse 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 : • modèle de référence : • 4 sources par cluster • WPM basique : • 4 sources (cluster 64-bit) – 3 sources (cluster 16-bit) • WPM optimisé : • 3 sources par cluster

40. Modèle WPMDistribution des instructions (2) • Heuristique : Soit i, l’instruction à assigner : • Tous les opérandes sources de i appartiennentauRF16: • 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 WPManalyse 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 WPManalyse de la complexité (2)