tude de cas

1
Étude de cas

• Maintenant quon a vu les pipelines, le
  superscalaire, le VLIW, la gestion des
  branchements Nous verrons comment le tout est
  intégré dans quelques processeurs connus
• La famille Pentium, Pentium Pro, Pentium II,
  Pentium MMX, Pentium III, (Pentium 4)
• Le processeur Itanium de Intel / HP
• Le processeur Crusoë de Transmeta

2
Note de départ

• Nous parlerons ici de processeurs pour lesquels
  tous les détails techniques ne sont pas
  disponibles. Ce qui suit est donc incomplet, et
  peut contenir des erreurs.

3
Cas 1 Famille Pentium

• Lensemble dinstructions (ISA Instruction Set
  Architecture) x86 débute avec le processeur CISC
  8086, suivi par la suite des processeurs
  scalaires 8088, 80286, Intel386, Intel486, suivi
  des processeurs superscalaires des familles P5 et
  P6
• Le premier Pentium fait partie de la famille P5
• Cest une machine superscalaire qui peut émettre
  2 instructions par coup dhorloge
• La famille P6 apparaît en 1995, avec le Pentium
  Pro, suivi du Pentium MMX (P5) et du Pentium II
  (P6) en 1997
• En 1999, on introduit les instructions  Internet
  Streaming SIMD extension  (ISSE), avec le
  Pentium III
• Fin 2000, apparaît le Pentium 4, avec ISSE 2, et
  le  hyper pipelining  (pipeline de 20 étages)

4
Cas 1 Famille Pentium
5
Cas 1 Famille Pentium

• Pentium II
• Exécution dinstructions dans le désordre,
  utilisation du  register renaming  ?
  Utilisation de la méthode de Tomasulo
• Mémoire cache séparée pour les instructions et
  les données
• ISA IA-32, instructions x86 transformées en
  instructions pseudo-RISC (?ops) envoyées dans une
  station de réservation centralisée (appelée
   instruction window )
• Les ?ops peuvent être exécutées dans le désordre,
  mais avant (et après) leur exécution elles sont
  envoyées à un tampon qui écrit les résultats dans
  le bon ordre ( reorder buffer )

6
Cas 1 Microprocesseur Pentium II
7
Cas 1 Microprocesseur Pentium II (Décodage)
8
Cas 1 Microprocesseur Pentium II (Décodage)

• Lunité  Next IP  génère ladresse pour le
  I-Cache
• Basé sur linformation provenant du BTB, qui
  utilise un prédicteur adaptif 2 niveaux (type Yeh
  et Patt)
• Le BTB a 512 entrées
• Les branches mal prédites causent un délai moyen
  de 15 cycles (minimum 11 cycles)

9
Cas 1 Microprocesseur Pentium II (Décodeur)
10
Cas 1 Microprocesseur Pentium II (Décodeur)

• Le Décodeur lit 16 octets, et aligne les octets
  des instructions (jusquà 7 octets /
  instruction), qui sont de taille variable
• Il y a 3 unités de décodage
• Le décodeur général (traite les instructions
  complexes, et génère de 1 à 4 ?ops)
• 2 décodeurs simples (traitent les instructions de
  LOAD et registre-à-registre, générant 1 ?op)
• Le décodeur peut générer jusquà 6 ?ops par cycle
• La station de réservation peut accepter jusquà 3
  ?ops par cycle

11
Cas 1 Microprocesseur Pentium II (Décodeur)

• Les ?ops sont des instructions pseudo-RISC, de
  taille fixe, qui contiennent un code dopération,
  deux opérandes pour les sources, et un opérande
  pour la destination
• Les instructions x86 les plus complexes (celles
  qui requièrent plus de 4 ?ops) sont décodées à
  laide du  Microcode Instruction Sequencer 
• Instructions registres-à-registres 1 ?op
• Instructions Load 1 ?op
• Instructions Store, Read / Modify 2 ?ops
• Instructions registres-mémoire 2- 3 ?ops
• Instructions Read / Modify / Write 4 ?ops
• RAT Conversion de registres en étiquettes liées
  au matériel
• Ensuite, les ?ops sont envoyées au ROB et au RSU

12
Cas 1 Microprocesseur Pentium II (ROB et RSU)
13
Cas 1 Microprocesseur Pentium II (ROB et RSU)

• Le ROB garde en mémoire lordre des ?ops, pour
  quà la fin de leur exécution elles puissent être
   retirées  (retired) dans le bon ordre
  (écriture dans les registres ou en mémoire)
• Le RSU contient une fenêtre de 20 ?ops, qui
  peuvent être exécutées dans le désordre

14
Cas 1 Microprocesseur Pentium II (Reorder Buffer
- ROB)

• Le ROB est utilisé à deux reprises dans le
  processeur
• Entre le décodage des instructions et lexécution
  des ?ops
• On indique alors lordre relatif des ?ops dans
  une instruction et des ?ops appartenant à des
  instructions distinctes
• Après lexécution, pour les retirer dans le bon
  ordre
• Retirer une instruction, cest écrire de façon
  permanente (commit) les changements de valeurs de
  registres et de la mémoire, dans une mémoire
  tampon temporaire, le Retirement Register File
  (RRF)
• Le processeur peut retirer 3 ?ops par coup
  dhorloge
• Une ?op peut être retirée si
• Son exécution est terminée
• Toutes les autres ?ops de la même instruction
  sont terminées (?)
• Toutes les autres instructions qui précèdent sont
  terminées (et leurs ?ops respectives)
• Il ny a pas eu dinterruption, dexception ou
  derreur de prédiction de branchement

15
Cas 1 Microprocesseur Pentium II (Exécution)
16
Cas 1 Microprocesseur Pentium II (Exécution)
17
Cas 1 Microprocesseur Pentium II (Exécution)

• Si une ?op a les valeurs de ses opérandes
  dentrées, et que le FU requis est libre, le RSU
  peut faire lémission
• Le RSU peut émettre jusquà 5 ?ops par cycle (une
  par port), mais en moyenne cest 3 ?ops

18
Cas 1 Microprocesseur Pentium II (Exécution)
19
Cas 1 Microprocesseur Pentium II (Pipeline)
20
Cas 1 Microprocesseur Pentium 4 (Diagramme)
21
Cas 1 Microprocesseur Pentium 4 (Pipeline)

• Le pipeline du Pentium 4 a 20 étages ( environ 2
  fois plus que le Pentium III)
• Avantage il est plus facile daugmenter la
  fréquence de lhorloge
• Inconvénient remplir / vider le pipeline prend
  du temps

22
Cas 2 Itanium

• Développé conjointement par HP et Intel
• ISA mis au point chez HP
• Design matériel principalement chez Intel
• But mettre au point la prochaine génération de
  processeurs haute performance 64 bits
• Principes de base éliminer les goulots
  détranglements connus des systèmes
  superscalaires existants

23
Cas 2 Itanium (2)

• Ce qui limite la performance dans les systèmes
  superscalaires  standard 
• Les branchements
• Les mauvaises prédictions limitent la performance
• Les petites branches (peu de code) ont peu de
  code à exécuter, ce qui limite le parallélisme
• Laccès à la mémoire
• Utilise plus dun coup dhorloge
• Souvent, on doit faire un load juste après un
  branchement
• Lextraction du parallélisme des instructions
• Le compilateur  sérialise  le code, dont le
  parallélisme intrinsèque doit être redécouvert
  dynamiquement par le processeur

24
Cas 2 Itanium Les limites de la performance
Branchements

• Erreurs de prédiction limitent la performance
• Les petits blocs de destination limitent le
  parallélisme
• Mauvaise utilisation des machines ayant beaucoup
  dunités dexécution

IF
THEN
ELSE
25
Cas 2 Itanium Les limites de la performance
(2) Latence de la mémoire

• Temps daccès à la mémoire augmente
  continuellement par rapport à la vitesse des
  processeurs
• Délais de chargement exacerbés par les machines
  qui exécutent plus dune instruction par coup
  dhorloge

Le branchement est une barrière
Machine scalaire
Machine 4 X superscalaire
26
Cas 2 Itanium Les limites de la performance
(3) Extraction du parallélisme

• Modèle dexécution séquentiel
• Le compilateur a une vue limitée, indirecte du
  matériel

27
Cas 2 Itanium Meilleure stratégie
parallélisme explicite

• Le compilateur expose, améliore et exploite le
  parallélisme du programme source et le rend
  explicite dans le code machine

28
Cas 2 Itanium Format des instructions

• Les instructions sont regroupées en paquets de
  128 bits
• Chaque instruction fait 40 bits
• Il y a un gabarit (template) de 8 bits qui
  indique quelles instructions peuvent sexécuter
  en parallèle
• Permet au compilateur dextraire plus de
  parallélisme
• Simplifie le matériel en éliminant les mécanismes
  de détection dynamiques
• Augmentation modeste de la taille du code
• Instructions EPIC Explicitely Parallel
  Instruction Computing (parallélisme explicite
  grâce aux gabarits)

29
Cas 2 Itanium Branchements traditionnels

• Architecture traditionnelle 4 blocs de base
• Les conditions introduisent des branchements

30
Cas 2 Itanium Utilisation de  prédicats 
31
Cas 2 Itanium Utilisation de  prédicats 

• Les prédicats permettent une meilleure
  utilisation du matériel parallèle

32
Cas 2 Itanium Utilisation de  prédicats 

• Le compilateur a une plus grande marge de
  manuvre pour faire le  scheduling  des
  instructions
• La plupart des instructions peuvent inclure des
  prédicats
• Létat de la machine (les registres et la
  mémoire) ne sont mis à jour que si le prédicat
  est vrai. Sinon, linstruction devient
  effectivement un NOP
• Le compilateur assigne des prédicats aux
  instructions, qui sont déterminés par les
  instructions de comparaison
• EPIC définit 64 registres de prédicats à 1-bit
• Lutilisation de prédicats élimine les
  branchements
• Convertit une dépendance de contrôle en
  dépendance de données
• Réduit les pénalités pour les mauvaises
  prédictions
• Exécution parallèle de plus dinstructions
• Utilisation plus efficace du matériel parallèle
• Sur les SPEC89, près de ½ des branchements sont
  éliminés

33
Cas 2 Itanium Délais daccès à la mémoire avec
les machines traditionnelles

• La lecture de la mémoire affecte la performance
  de façon majeure
• Souvent le LOAD est la 1ère instruction dune
  cahîne dinstructions dépendantes
• Il peut y avoir une grande latence
• Les LOAD peuvent causer des exceptions

34
Cas 2 Itanium Spéculation
Architecture EPIC

• On sépare la lecture du traitement des exceptions
• Linstruction de lecture spéculative (ld.s)
  démarre un Load et détecte les exceptions
• Les exceptions sont propagées (à laide dun
  jeton attaché au registre de destination) de ls.s
  à chk.s
• La vérification spéculative (chk.s)  rend
  publiques  les exceptions détectées par ld.s

35
Cas 2 Itanium Spéculation

• Donne plus de liberté au compilateur pour le
  scheduling
• Permet aux instructions ld.s dapparaître avant
  les branchements
• Chk.s demeure à sa position initiale, et initie
  une correction si une exception est détectée

36
Cas 2 Itanium Exemple - La boucle des 8 Reines
if ((b j true) (a i j true)
(c i - j 7 true))
Vrai Mauvaise préd 38 43 72
33 47 39
37
Cas 2 Itanium Exemple - La boucle des 8 Reines
if ((b j true) (a i j true)
(c i - j 7 true))
13 cycles, 3 mauvaises prédictions possibles
9 cycles, 3 mauvaises prédictions possibles
38
Cas 2 Itanium Exemple - La boucle des 8 Reines
if ((b j true) (a i j true)
(c i - j 7 true))
39
Cas 2 Itanium Exemple - La boucle des 8 Reines
if ((b j true) (a i j true)
(c i - j 7 true))
40
Cas 2 Itanium - Conclusion

• EPIC (Explicitely Parallel Instruction Computing)
• Utilise du code assembleur où le parallélisme est
  indiqué explicitement avec des gabarits
  (templates)
• Utilise la prédication pour éliminer les
  branchements (utilisation de 64 registres de
  statut qui permettent lexécution conditionnelle
  dinstructions)
• Utilise la spéculation pour diminuer limpact des
  Loads (on sépare le chargement du traitement des
  exceptions)
• Architecture des instructions faite pour que les
  processeurs soient facilement améliorés par des
  ajouts de matériel parallèle supplémentaire

41
Cas 3 Crusoë de Transmeta

• Processeur destiné au marché des machines
  portables
• Requiert très peu de puissance électrique comparé
  à dautres processeurs ayant des performances
  semblables
• Attrait intéressant utilise un noyau VLIW sur
  lequel un émulateur logiciel peut interpréter
  des instructions destinées à un autre processeur
• Transmeta a démontré lutilisation dune
  application hybride Java / x86, où lensemble des
  instructions sont exécutées (interprétées et
  traduites) sur le VLIW sous-jacent

42
Cas 3 Crusoë de Transmeta

• Pour contrôler ses besoins de puissance
  électrique, Crusoe détecte si le système est peu
  utilisé, et à la fois réduit la fréquence de
  lhorloge (de 700 MHz à 200MHz) et le potentiel
  dalimentation (de 1,65 V à 1,1 V)
• Puisque P ½ f C V2,
• La puissance est diminuée de (700 / 200) (1,65
  / 1,1)2
• et P (1 / 7,88) P (près de 8 fois moins
  de puissance)

43
Cas 3 Crusoë CMS (Code Morphing Software)

• Le processeur Crusoe est un VLIW sur lequel
  sexécute un logiciel dinterprétation
  dinstructions x86

44
Cas 3 Crusoë - CMS

• Le CMS (Code Morphing System)
• Interprétation des instructions x86 en
  instructions VLIW
• Mise en mémoire des séquences dinstructions
  fréquentes
• Réutilisation des instructions déjà traduites

45
Cas 3 Crusoë Diagramme

• Diagramme du 5400

46
Cas 3 Crusoë

• Le 5400