Περιεχόμενα

Πανεπιστήμιο Πατρών, Τμήμα Ηλεκτρολόγων Μηχανικών & Τεχνολογίας Υπολογιστών

Αρχιτεκτονική Επεξεργαστών

Από Τον 80386 Στον Pentium 4 Στέφανος Καξίρας{ [email protected], [email protected] }


Περιεχόμενα

Αρχιτεκτονική και ο νόμος του Moore Σετ εντολών

• Ο πόλεμος των σετ εντολών: RISC εναντίον CISC Από το μικροκώδικα στο pipelining

• 80386 -> 80486 Σπάζοντας το φράγμα του 1 IPC: superscalar

• 80486 -> Pentium Το επόμενο βήμα: ΕΕΣ (OOO)

• Pentium -> Pentium Pro/ΙΙ/ΙΙΙ, Pentium 4 Μνήμη

• Caches Κατανάλωση Ισχύος


Αρχιτεκτονική και ο Νόμος του Moore

Νόμος του Moore

• Ο αριθμός των τρανζίστορ στα ολοκληρωμένα κυκλώματα διπλασιάζεται κάθε ~ 2 χρόνια

• Intel 4004 (1971): 2300, Pentium 4 (2001): 55.000.000



Στην πραγματικότητα η απόδοση (ταχύτητα επεξεργασίας για συγκεκριμένα προγράμματα) των επεξεργαστών διπλασιάζεται σε λιγότερο από 2 χρόνια

Σε λιγότερο από 2 χρόνια θα κάνουμε τόση πρόοδο όση κάναμε στα προηγούμενα 28 χρόνια ...

Είναι αυτό αποτέλεσμα του νόμου του Moore?

• Μικρότερα τρανζίστορ = πιο γρήγορα τρανζίστορ = πιο πολλά MHz = απόδοση ?

• OXI



Η αρχιτεκτονική είναι αυτή που μεταφράζει τα κέρδη στην πυκνότητα και ταχύτητα των τρανζίστορ σε κέρδη στην απόδοση του επεξεργαστή.

Παράδειγμα 1: Το χάσμα της μνήμης (memory gap/wall)

• Την εποχή του Intel 8086 η μνήμη DRAM ήταν πιο γρήγορη από τον επεξεργαστή. Ένα LOAD πιο γρήγορο από ένα ADD.

• Σήμερα ένα LOAD ~ 70 κύκλους του επεξεργαστή, ίσως ~ 140 εντολές (ADD) !

• Αλλά η αναλογία των LOAD στα προγράμματα παραμένει η ίδια …

• Λύση ? Αρχιτεκτονική:

— Cache memories, “κρυφές” “γρήγορες” μνήμες

— κάνουν τη DRAM να φαίνεται γρήγορη ...



Παράδειγμα 2: παραλληλισμός στην εκτέλεση εντολών

• Την εποχή του Intel 8086 μια εντολή χρειαζόταν πολλούς κύκλους για να εκτελεστεί

• Σήμερα ένας Pentium 4 μπορεί να εκτελέσει ταυτόχρονα στον ίδιο κύκλο 6 εντολές

• Εάν δεν μπορούσαμε να εκτελέσουμε πολλές εντολές κάθε κύκλο η αύξηση της απόδοσης θα υπολείπονταν της αύξησης συχνότητας (που έτσι και αλλιώς είναι μικρότερη από 2x/2,5χρόνια).

Αυτά τα δύο παραδείγματα αποτελούν την ουσία της σύγχρονής αρχιτεκτονικής


Σετ εντολών

Η αρχιτεκτονική του σετ εντολών (ISA) ενός επεξεργαστή είναι το interface με τον έξω κόσμο.

Το σετ εντολών καθώς, η διαχείριση μνήμης (Εικονική μνήμη, virtual memory) και ο χειρισμός των διακοπών (interrupts) ορίζουν την συμπεριφορά του επεξεργαστή.

Έχει σημασία το σετ εντολών για το πόσο εύκολο είναι αρχιτεκτονικά να αποσπάσουμε την μέγιστη απόδοση από έναν επεξεργαστή ?



Τη δεκαετία του 80 οι μικροεπεξεργαστές με αρχηγό την Intel αλλά και άλλους (π.χ. Moto. 68000, Nat. Semi. 32032) ακολουθούσαν τους κατασκευαστές των mini (IBM, DEC VAX-11) και ολοένα παρουσίαζαν πιο πολύπλοκα σετ εντολών

Οι εντολές γινόταν όλο και πιο σύνθετες, πλησιάζοντας τις γλώσσες υψηλού επιπέδου («semantic gap», VAX 11)

Η αποκορύφωση ήταν ο Intel 432, ένας φοβερά πολύπλοκος επεξεργαστής και μια φοβερή εμπορική αποτυχία της Intel.



Επικρατούσα αρχιτεκτονική: αρχιτεκτονική με μικροκώδικα:

• ένα μικροπρόγραμμα που έτρεχε συνεχώς σε ένα υποτυπώδη κρυφό επεξεργαστή διάβαζε τις (μακρο)εντολές του προγράμματος μια-μια και ενορχήστρωνε την εκτέλεσή τους κατευθείαν πάνω στο υλικό χρησιμοποιώντας όμως πολλούς κύκλους για κάθε μακροεντολή

Δεδομένου του περιορισμένου αριθμού τρανζίστορ

• Αύξηση της πολυπλοκότητας του σετ εντολών με μεγαλύτερο μικροκώδικα

Δυνατότερες εντολές = καλύτερη απόδοση ? CISC



RISC: Αντίδραση στην αύξηση της πολυπλοκότητας ήρθε από το Stanford (MIPS) και το Berkeley (RISC-I, RISC-II, SUN SPARC)

Δεδομένου του περιορισμένου αριθμού τρανζίστορ

• Αύξηση της απόδοσης με απλούστερο σετ εντολών (στα βήματα των CRAY και CDC 6600)

Mικροεντολές -> σετ εντολών


RISC εναντίων CISC

RΙSC CISC Διαφορά σε 32 bit Μεταβλητού μήκους Decode Ομοιόμορφες Πολλές μορφές Decode

Εντολές

Απλές Πολύπλοκες Execute Καταχωρητές Πολλοί Λίγοι Pipelining

Λίγα Πολλά Decode

Απλά Πολύπλοκα Execute

Addressing Modes

Χρήσιμα σε compilers

Αχρησιμοποίητα από compilers

Εκτέλεση Load-store Memory-memory Pipelining


RISC εναντίων CISC

Δεδομένου του περιορισμένου αριθμού τρανζίστορ και με πάρα πολλούς πόρους διαθέσιμους...

IA-32, x86(CISC) Εσωτερική μετάφραση σε RISC μ-ops P-PRO/ I I / I I I /4

Μεταβλητού μήκους Σταθερού μήκους 118bit Πολλές μορφές -

Εντολές

Πολύπλοκες Απλές Καταχωρητές Λίγοι

(αρχιτεκτονικοί) Πάρα πολλοί εσωτερικοί (physical registers)

Πολλά

Πολύπλοκα

Addressing Modes

Αχρησιμοποίητα από compilers

Μετάφραση σε πράξεις με διευθύνσεις

Εκτέλεση Memory-memory Load-store εσωτερικα


Η κατάληξη

Παρόλο που το RISC ήταν πολύ επιτυχημένο την εποχή που παρουσιάστηκε (2,6x RISC advantage), το CISC κατόρθωσε να επιζήσει και να επικρατήσει

Το CISC μπόρεσε να εκμεταλλευτεί όλες τις καινοτομίες του RISC, κυρίως ΟΟΟ, caches

Η αρχιτεκτονική όπως εκφράζεται σήμερα αναφέρεται στο εσωτερικό RISC πυρήνα των επεξεργαστών (είτε είναι Pentium 4 είτε οτιδήποτε άλλο)

Το “εξωτερικό” σετ εντολών δεν καθορίζει πια την “εσωτερική” αρχιτεκτονική ενός επεξεργαστή

• TRANSMETA CRUSOE (Pentium compatible): μεταφράζει το ΙΑ-32(x86) στο δικό του σετ εντολών (VLIW) και μετά το εκτελεί !






• 80486 -> Pentium Το επόμενο βήμα: OOO, Εκτέλεση Εκτός Σειράς

• Pentium -> Pentium Pro/2/3, Pentium IV Μνήμη



Από τον μικροπρογραμματισμό στο pipelining: 80386 -> 80486

80386 (1986), IA-32, x86 8 registers Αρχιτεκτονική μικροκώδικα

• ένα μικροπρόγραμμα τρέχει συνεχώς σε ένα υποτυπώδη κρυφό επεξεργαστή, διαβάζει τις x86 εντολές του προγράμματος μια-μια και ενορχηστρώνει την εκτέλεσή τους κατευθείαν πάνω στο υλικό, χρησιμοποιώντας όμως πολλούς κύκλους για κάθε x86 εντολή

π.χ. fetch - decode - execute


80386

sum=0for i=0 to 10 sum+=a[i]

i1 r1=0 /* index */i2 r0=0 /* sum */i3 loop:r2=MEM[a+r1] /* a[i] */i4 r0=r0+r2 i5 r1=r1+1i6 r3=(r1 != 10)i7 if(r3==true) goto loop

r2=MEM[a+r1] r0 = r0 + r2 r1 = r1 + 1 r3 = r1!=10

fetch i4 decode i4 r0=r0+r2 fetch i5 decode i5 r1=r1 + r2

1 2 543 6


Από τον μικροπρογραμματισμό στο pipelining: 80386 -> 80486

80486 (1989) 1.000.000 τρανζίστορ, 2ο chip με > 1M τρανζίστορ (πρώτο με διαφορά μηνών το i860)

Αρχιτεκτονική Pipeline/μικροκώδικα Pipeline: επικάλυψη των σταδίων εκτέλεσης των εντολών

(π.χ. Fetch, decode, execute)

• Σαν τις αλυσίδες παραγωγής αυτοκινήτων (π.χ., αμάξωμα, σαλόνι, μηχανή, βάψιμο)

Ποιες εντολές εκτελούνται στο pipleline του 80486?

• Απλές, RISC-like,

• οι υπόλοιπες … με μικροκώδικα Pipeline παράδειγμα fetch - decode - execute (στον 80486 5

στάδια)


80486



r2=MEM[a+r1] r0 = r0 + r2 r1 = r1 + 1 r3 = r1!=10

fetch i4 decode i4 r0=r0+r2

fetch i5 decode i5 r1=r1+1

fetch i6 decode i6 r3=r1!=10

1 2 543


Pipelining

Απαράβατος Κανόνας: διατηρούνται τα Sequential Semantics, εντολές εκτελούνται με τη σειρά που εμφανίζονται στο πρόγραμμα

• Εντολές χωρίζονται σε δύο κατηγορίες

— In-progress: αποτελέσματά τους αόρατα στην εξωτερική κατάσταση του επεξεργαστή

— Committed: τα αποτελέσματά τους ορατά στη κατάσταση του επεξεργαστή

Το pipelining βελτιώνει μόνο το Ρυθμό (throughput) ΟΧΙ την καθυστέρηση (latency)

• η κάθε εντολή είναι όσο αργή ήταν και πριν (π.χ. 3κ.)

• 1000 εντολές 1002 κύκλους (χωρίς pipelining 3000 κύκλους). Στο ΟΡΙΟ 1 εντολή ανά κύκλο.


Pipelining

Το pipeline πρέπει να είναι ΠΑΝΤΑ γεμάτο

• Data hazzards

— RAW: read after write

– δεν μπορούμε να εκτελέσουμε αν το αποτέλεσμα δεν είναι έτοιμο

– load X; A=A+X;

• Control Hazzards

— Δεν μπορούμε να αποφασίσουμε γρήγορα από που θα κάνουμε fetch

— Βλέπε branch prediction


80486: RAW pipeline bubble



r2=MEM[a+r1] r0 = r0 + r2 r1 = r1 + 1 r3 = r1!=10

fetch i3 decode i3 r2=[a+r1]

fetch i4 decode i4 STALL

fetch i5 decode i5 STALL

1 2 543

r0=r0+r2


80486: JMP pipeline bubble



fetch i7 decode i7 jmp i3

fetch i8 decode i8 KILL

fetch i9 KILL KILL

1 2 543 fetch i3 decode i3


Superscalar: 80486 -> Pentium

Pentium 1993, 3.100.000 τρανζίστορ με 16KB cache Ορισμός του superscalar: διαδοχικές εντολές παράλληλα Εκτέλεση σε σειρά, μέχρι 2 εντολές τον κύκλο Δύο pipelines, 5-στάδια η κάθε μία Ασύμμετρα pipelines: το ένα πιο “ικανό” από το άλλο Εύκολες, ανεξάρτητες διαδοχικές εντολές παράλληλα,

διαφορετικά μία-μία στο κύριο pipeline Δύσκολες εντολές με μικροπρόγραμμα π.χ. Dual Superscalar Pipeline : fetch - decode - execute


Pentium



r2=MEM[a+r1] r0 = r0 + r2 r1 = r1 + 1 r3 = r1!=10

fetch i4

fetch i5

decode i4 r0=r0+r2

decode i5 r1=r1+1

fetch i6 decode i6 r3=r1!=10

1 2 543

fetch i3 decode i3 r2=M[a+r1]


Superscalar: 80486 -> Pentium

Τι υλικό χρειάζεται για superscalar ? Στο decode πρέπει να αποφασίσουμε αν οι εντολές μπορούν να

εκτελεστούν παράλληλα

• Ανεξαρτησία εντολών: Εξάρτηση των εντολών εκδηλώνεται μέσα από την εγγραφή/ανάγνωση καταχωρητών:

— RAW: Μια εντολή χρειάζεται το αποτέλεσμα μιας άλλης

— WAR, WAW hazards (κίνδυνοι)

• resource hazards: αν οι εντολές χρειάζονται τους ίδιους πόρους για την εκτέλεσή τους

• Control Hazzards “Bypass networks” για τα pipelines και μεταξύ των pipelines

— Παράκαμψη του πίνακα καταχωρητών (RF) για τη μεταφορά αποτελεσμάτων από εντολή σε εντολή

— γράψιμο, ανάγνωση καταχωρητών πολύ αργό


OOO: Pentium->Pentium Pro/II/III

Pentium Pro (1995) 5,5M τρανζίστορ (2x8KB L1) Pentium II (1997) 7,5M - 27,4M (2x16KB L1, 256KB L2) Pentium III (1999) 9,5M - 44M (2x16KB L1, 512KB L2) O πρώτος OOO επεξεργαστής. Dynamic Execution (Intel),

Out-of-Order, Εκτέλεση εκτός σειράς προγράμματος ΟΟΟ ? Σαν το SUPERSCALAR αλλά οι εντολές που

εκτελούνται παράλληλα ΔΕΝ χρειάζεται να είναι διαδοχικές Μετάφραση των x86 εντολών σε RISC μ-Ops 14 στάδια pipeline (12 σε σειρά 2 εκτός σειράς) μέχρι 5 μ-Ops παράλληλα σε 5 FUs:

• 2 x ALU, LOAD, STORE, FPU


OOO: Pentium->Pentium Pro/II/III

Γιατί χρειάζεται το ΟΟΟ? Δεν φτάνει μόνο το SUPERSCALAR? Ας πούμε ότι έχουμε 2 pipelines διαθέσιμα

Ο παραλληλισμός ΔΕΝ βρίσκεται σε διαδοχικές εντολές (που συνήθως εξαρτώνται η μια από την άλλη) ΑΛΛΑ ΠΙΟ ΜΑΚΡΥΑ

/* C =((A+1)/2)-((B+1)/2) */i1 r1 = MEM[A]i2 r2 = r1+1i3 r3 = r1/2i4 r4 = MEM[B]i5 r5 = r4+1i6 r6 = r5/2i7 r7 = r3-r6i8 MEM[C] = r7

i1i2i3i4i5i6i7i8

i1i4i2i5i3i6i7i8

SUPERSCALAR OOO


OOO: Pentium Pro/II/IIIsum=0for i=0 to 10 sum+=a[i]


fetch i4 decode i4

fetch i5 decode i5

fetch i6 decode i6

1 2 543


r3=r1!=10 Commit

Commit

Commit

Commit

Stall

Stall

r1=r1+1

r0=r0+r2


Pentium Pro Pipeline (Conceptual)

DECODE

FETCH

DISPATCH

EXECUTE

RETIRE(COMMIT)

Decoupled(διαφορετικός

ρυθμός εκτέλεσης)

Decoupled

FRONT END

BACK END

EXEC


Pentium Pro/II/III block diagram (απλοποιημένο)

IFCfetch

Decode

x86 εντολές

DispatchRS20

Decode

Decode

ALU0

AGU1 LD

AGU2 ST

FPU

ALU1JmpI-Cache

ROB40

Registerfile40

RRFIA-32x86

10 στάδια 1-n στάδιαFRONT END BACK END

(COMMIT)

4C

2C

2C2C

2C

1-n C

EXEC


Instruction Decode

Convert x86 instructions into μops (uops)Uops: 2-operand RISC instructions:

x86 (IA-32):

add (eax), (ebx) MEM(eax) <- MEM(eax) + MEM(ebx)

UOPS:

ld guop0, (eax) guop0 <- MEM(eax)

ld guop1, (ebx) guop1 <- MEM(ebx)

add guop0, guop1 guop0 <- guop0 + guop1

sta eax

std guop0 MEM(eax) <- guop0


Pentium Pro/II/IIIInstruction flow

IFCfetch

short

x86 εντολές

DispatchRS20

long

short

ALU0

AGU1 LD

AGU2 ST

FPU

ALU1JmpI-Cache

ROB40

Registerfile40

RRFIA-32x86

1-3x86

instructions

16b instr.buffer

6 uopbuffer

1 uop1 uop4 uops

3 uop rename &dispatch

Up to5 uops issue/c

Up to5 uops exec/c

3 uop retirecommit/c


AMD K6 Instruction Decode

X86 -> RiscOPs (πιο ισχυρά από τα uops)2 ισχυρούς decoders vs. 3 της IntelPredecoding

• 32K Instruction cache + 20K predecode bits (5 bits/byte)


Το πρόβλημα με τα branch (JUMP)

fetch i4 decode i4


fetch i6 decode i6


r0=r0+r2

r3=r1!=10 Commit

Commit

Commit

Commit

Stall

Stall

fetch i7 decode i7 Stall if r3 loopStall

fetch i4

fetch i5

fetch i6

fetch i3

fetch i7

Commit


Branch prediction

Pipeline Πάντα γεμάτο … Pentium Pro: 12 pipeline στάδια πριν από την εκτέλεση =

12 * 3 εντολές μετά από ένα branch (JUMP) Πού θα τις βρούμε όλες αυτές τις εντολές ?

• Πρόβλεψη branch

• Ποντάρουμε στο ότι το i7 μάλλον θα πάει στο i3 και όχι στο i8

i1 r1=0 /* index */i2 r0=0 /* sum */i3 loop:r2=MEM[a+r1] /* a[i] */i4 r0=r0+r2 i5 r1=r1+1i6 r3=(r1 != 10)i7 if(r3==true) goto loopi8 continue: ...


Branch prediction

fetch i4 decode i4


fetch i6 decode i6


r0=r0+r2

r3=r1!=10 Commit

Commit

Commit

Commit

Stall

Stall


fetch i4 decode i4


fetch i6 decode i6


r0=r0+r2

r3=r1!=10 Commit

Commit

Commit

Commit

Stall

Stall


Commit

Πρόβλεψη

Πρόβλεψη


Pentium Pro branch prediction

IFCfetch

Decode

x86 εντολές

DispatchRS20

Decode

Decode

ALU0

AGU1 LD

AGU2 ST

FPU

ALU1JmpI-Cache

ROB40

Registerfile40

RRFIA-32x86

10 στάδια 1-n στάδια 2 σ.FRONT END

BACK END(COMMIT)

Branch Predict


Speculative execution

Η πρόβλεψη branch (JUMP) οδηγεί σε ΥΠΟΘΕΤΙΚΗ ΕΚΤΕΛΕΣΗ ΕΝΤΟΛΩΝ (Speculative Execution)

• υποθέτουμε ότι θα εκτελεστούν … Αν όμως κάνουμε λάθος ?

• Θα πρέπει τα αποτελέσματα της υποθετικής εκτέλεσης να είναι αναστρέψιμα

• Οι βασικοί μηχανισμοί υπάρχουν ήδη για το OOO

• Το ROB κρατάει τις υποθετικές εντολές ώσπου να επαληθευτεί η ροή του προγράμματος

• ROB (40) > RS (20)


Branch prediction

Branch (JUMP) ορολογία:

Πως γίνεται το branch prediction?

• Στατικά (π.χ. branch προς τα πίσω είναι “taken” )

• Με τη βοήθεια του compiler

• Δυναμικά (κατά την εκτέλεση του προγράμματος)

i-x loop: ...... ...i JUMP loopi+1 continue …i+2 ...

τaken (αλλαγή ροής)

not taken/fall-throughσυνέχεια ροής


Branch prediction

Δυναμικό branch prediction

• Απλοϊκό: για κάθε branch κάνε ότι έκανε την προηγούμενη φορά

— loop: 10 φορές σωστό, λάθος, λάθος, 9 φορές σωστό, λάθος, λάθος …

• για κάθε branch κάνε ότι έτεινε να κάνει πιο πολύ τις 2-3 πιο πρόσφατες φορές που το είδαμε (Jim Smith, UW, βραβείο Mauchley-Eckert), Pentium branch prediction, 256 br.

— loop: 10 φορές σωστό, λάθος, 10 φορές σωστό, λάθος...

i-x loop: ...... ...i JUMP loopi+1 continue …i+2 ...

τaken (αλλαγή ροής)

not taken/fall-throughσυνέχεια ροής


Branch prediction

Σύγχρονο branch prediction στον Pentium Pro/II/III Δύο επιπέδων, με ιστορία (two-level, history-based), Yeh &

Patt, UM Η συμπεριφορά του branch εξαρτάται από το τι έγινε με τα

άλλα branch πριν από αυτό Με άλλα λόγια από πιο δρόμο φτάσαμε σε αυτό το branch

• Ιστορία: τι έγινε με τα ν προηγούμενα branches

— π.χ. taken,fall-through,taken,taken (1,0,1,1)

• Πρόβλεψη: τι έτεινε να κάνει το branch (πιο πολύ) τις προηγούμενες 2-3 φορές που το είδαμε με την ίδια ιστορία

Pentium Pro: 4 προηγούμενα branch ιστορία (πχ. 1011) , προβλέπει 512 συνδιασμούς ιστορίας/branch

95% ακρίβεια πρόβλεψης


Βranch prediction

Πολύ προσοδοφόρο πεδίο (πολλές δημοσιεύσεις) Γιατί ? 90-95% επιτυχία πρόβλεψης δεν είναι αρκετή … Π.x.: καθημερινή πρόβλεψη σεισμών: σήμερα δεν θα γίνει

σεισμός: 99% επιτυχία

• Το θέμα είναι όμως πόσο “κοστίζει” η 1 (στις 100) λάθος πρόβλεψη

• Στους επεξεργαστές το κόστος λάθος πρόβλεψης αυξάνει διαρκώς (Pentium 4, 20-στάδια pipeline, 6 εντολές παράλληλα …)

Παραμένει ένα από τα δύσκολα προβλήματα που οδήγησε την Intel σε άλλες αρχιτεκτονικές : IA-64, Itanium που αποφεύγουν την πρόβλεψη


Register renaming

Ο παραλληλισμός δεσμεύεται από τις αλληλεξαρτήσεις των εντολών

• Αληθινές εξαρτήσεις: δεν μπορεί να εκτελεστεί μια εντολή πριν από τις εντολές που παράγουν τα ορίσματά της.

— RAW (Read-After-Write) εξαρτήσεις.

• Πλασματικές εξαρτήσεις: αποτροπή εκτέλεσης λόγω ανακύκλωσης των καταχωρητών

— WAW (Write-After-Write) αντι-εξάρτηση

— WAR (Write-After-Read) output εξάρτησηi1 r1 = r2 * 10i2 r3 = r1 * 10i3 r1 = r4 * 20i4 r5 = r1 * 20

Αντι-εξάρτηση WAWoutput-εξάρτηση WAR


Register renaming

Για τις αληθινές εξαρτήσεις χρειάζεται να περάσουμε σε εξελιγμένα είδη πρόβλεψης για να τις υπερβούμε (Value Prediction, dataflow barrier). Θεωρητικά μιλώντας...

Οι πλασματικές εξαρτήσεις μειώνουν τον παραλληλισμό στο επίπεδο εντολών (ILP) χωρίς να έχουν ουσιαστικό λόγο ύπαρξης. Απαλείφονται εύκολα αρκεί να είχαμε πάρα πολλούς καταχωρητές.

Αλλά το Σετ Εντολών ποτέ δεν αλλάζει (συμβατότητα λογισμικού). (μόνο επεκτείνεται …)

Λύση ? Μετονομασία Καταχωρητών (Register Renaming): Αντιστοίχισε τους καταχωρητές σε ένα πολύ μεγαλύτερο σετ, κατά την εκτέλεση του προγράμματος, αυτόματα και αόρατα στον εξωτερικό κόσμο.

Εξαλείφει το πλεονέκτημα των RISC που πάντα υποστήριζαν πολλούς καταχωρητές για τους ίδιους λόγους


Register renaming

i1 r1 = r2 * 10i2 r3 = r1 * 10i3 r1 = r4 * 20i4 r5 = r1 * 20

i1 ra = r2 * 10i2 r3 = ra * 10i3 r1 = r4 * 20i4 r5 = r1 * 20

i1 ra = r2 * 10i2 rb = ra * 10i3 rc = r4 * 20i4 r5 = rc * 20

Οι 8 “αρχιτεκτονικοί” καταχωρητές των x86 αντιστοιχίζονται σε 40 “φυσικούς” (physical) καταχωρητές

Ένας πίνακας (RAT, Register Alias Table) κρατά τις αντιστοιχίες

Κάθε φορά που γράφεται ένας αρχιτεκτονικός καταχωρητής αντιστοιχίζεται σε νέο φυσικό καταχωρητή

Με αυτό τον τρόπο εξαλείφουμε τις πλασματικές εξαρτήσεις (WAW, WAR) αλλά αφήνουμε ανέπαφες τις πραγματικές εξαρτήσεις (RAW)


Pentium Pro/II/III block diagram, register renaming

fetch

Decode

x86 εντολές

renameRS20

Decode

Decode

ALU

LOAD

STORE

FPU

ALU/JmpI-Cache

Branch Predict

ROB40

Registerfile40

RRFIA-32x86

10 στάδια 2 στάδια 2 σ.

RegisterAliasTable


Instruction decode

CISC -> RISC ?Στατικά

— Apple 68000 -> PowerPC

— Digital FX32! (x86 -> ALPHA)

Δυναμικά (κατά την εκτέλεση)

• Συνέχεια— Ppro,II,III, AMD K6, ...

• Μιά φορά— Transmeta Crusoe x86 -> VLIW

— Pentium 4 TRACE CACHE


Σύνοψη: OOO

Για να μεγιστοποιήσουμε τον παραλληλισμό στην εκτέλεση εντολών πρέπει να καταφύγουμε σε εκτέλεση εκτός σειράς προγράμματος (OOO).

Το OOO υποβοηθείται από:

• Πρόβλεψη ροής (Branch prediction) και υποθετική εκτέλεση (speculative execution)

— επιτρέπει (1) να βρούμε αρκετές εντολές ώστε να κρατάμε όλα τα pipelines γεμάτα, (2) να εκτελούμε εντολές υποθετικά ώσπου να επαληθεύσουμε τη ροή του προγράμματος

• Μετονομασία καταχωρητών (Register Renaming)

— αφαιρεί τις πλασματικές εξαρτήσεις μεταξύ εντολών που προέρχονται από την ανακύκλωση καταχωρητών


Pentium 4

IFCfetch

Decode

x86 εντολές

DispatchDecode

Decode

I-Cache

Trace Cache12K uops

6-uop lines

RS,EXEC

Multiple branch

prediction

PC + predictions

Trace genarator


Instruction Issue

Reduced function unit utilization due to dependencies

Time


Superscalar Issue

Superscalar leads to more performance, but lower utilization

Time


Predicated Issue

Adds to function unit utilization, but results are thrown away

Time


Chip Multiprocessor

Limited utilization when only running one thread

Time


Fine Grained Multithreading

Intra-thread dependencies still limit performance

Time


Simultaneous Multithreading

Maximum utilization of function units by independent operations

Time


Basic Out-of-order Pipeline

Fetch Decode/Map

Queue Reg Read

Execute

Dcache/Store Buffer

Reg Write

Retire

PC

Icache

RegisterMap

DcacheRegs Regs

Thread-blind


SMT Pipeline

Fetch Decode/Map

Queue Reg Read

Execute

Dcache/Store Buffer

Reg Write

Retire

IcacheDcache

PC

RegisterMap

Regs Regs


Changes for SMT

Basic pipeline – unchanged

Replicated resources• Program counters• Register maps

Shared resources• Register file (size increased)• Instruction queue• First and second level caches• Translation buffers• Branch predictor


Multiprogrammed workload

0%

50%

100%

150%

200%

250%

SpecInt SpecFP Mixed Int/ FP

1T2T3T4T


Decomposed SPEC95 Applications

0%

50%

100%

150%

200%

250%

Turb3d Swm256 Tomcatv

1T2T3T4T


Multithreaded Applications

0%

50%

100%

150%

200%

250%

300%

Barnes Chess Sort TP

1T2T4T






• 80486 -> Pentium Το επόμενο βήμα: OOO, Εκτέλεση Εκτός Σειράς

• Pentium -> Pentium Pro/2/3, Pentium IV Μνήμη



Μνήμη

Bob Colwell (αρχιτέκτονας του Pentium Pro) ISCA 2002 keynote address

An Unbalanced System


Μνήμη

Το χάσμα της Μνήμης (Memory Wall, Memory Gap) H ταχύτητα των επεξεργαστών αυξάνεται πολύ πιο πολύ από

αυτή της μνήμης (DRAM)

Το χάσμα αυξάνεται 50% το χρόνο …

CPU 2x/2 χρόνια

DRAM 2x/10 χρόνια


Μνήμη

Λύση ?

• Ουσιαστικό χαρακτηριστικό της μνήμης: H μνήμη μπορεί να είναι ΤΕΡΑΣΤΙΑ ‘Η ΓΡΗΓΟΡΗ αλλά ΟΧΙ και τα δύο μαζί (VAST OR FAST)

• => Ιεραρχία μνήμης:

registersΜνήμη Cache Level 1

Μνήμη Cache L2,L3

ταχύτητα

μέγεθος

DRAM


Generations of Microprocessors

Time of a full cache miss in instructions executed:

1st Alpha (7000): 340 ns/5.0 ns = 68 clks x 2 or 136

2nd Alpha (8400): 266 ns/3.3 ns = 80 clks x 4 or 320

3rd Alpha (t.b.d.): 180 ns/1.7 ns =108 clks x 6 or 648


Cache

Μνήμες Cache

• SRAM, κοντά στον επεξεργαστή, αντικατοπτρίζουν τα πιο “χρήσιμα” περιεχόμενα της κύριας μνήμης

• Κάνουν την κύρια μνήμη να “φαίνεται” πιο γρήγορη

• Χαρακτηριστικά προσπέλασης μνήμης

— Temporal Locality

– Ότι προσπελάστηκε πρόσφατα είναι πιθανό να προσπελαστεί ξανά

— Spatial Locality

– Αν προσπελαστεί μια θέση μνήμης τότε είναι πιθανό ότι θα προσπελαστούν και οι κοντινές σε αυτή


Cache

Λειτουργία

• Σε κάθε προσπέλαση κοιτάμε αν τα περιεχόμενα της μνήμης στη ζητούμενη διεύθυνση βρίσκονται στην cache.

• Ναι: cache HIT

— Hit rate: ποσοστό προσπελάσεων που πετυχαίνουν

• Όχι: cache MISS

— Θέση στη cache κενή ? Φέρε τα δεδομένα από τη μνήμη

— Θέση στη cache πιασμένη από άλλα δεδομένα (άλλη διεύθυνση μνήμης) ? cache REPLACEMENT:

– γράψε στη μνήμη τα παλιά δεδομένα (αν χρειάζεται) και φέρε τα νέα

— miss rate: ποσοστό που αποτυχαίνει (100-hit rate)


Χαρακτηριστικά Cache

Είδος δεδομένων

• εντολές, instruction cache

• δεδομένα, data cache

• ενοποιημένη, unified cache Τοποθεσία

• εσωτερική

• εξωτερική

• L1 (level 1) Eπίπεδο Ιεραρχίας, L1 πιο κοντά στον επεξεργαστή

• L2, L3


Four Questions for Memory Hierarchy Designers

Q1: Where can a block be placed in the upper level? (Block placement)

• Fully Associative, Set Associative, Direct Mapped Q2: How is a block found if it is in the upper level?

(Block identification)

• Tag/Block Q3: Which block should be replaced on a miss?

(Block replacement)

• Random, LRU Q4: What happens on a write?

(Write strategy)

• Write Back or Write Through (with Write Buffer)


Block Identification

Πως βρίσκουμε τι υπάρχει στην cache και τι όχι ? Ζητούμενη διεύθυνση χωρίζεται σε 3 μέρη: block, index, tag Το index μας δίνει τη θέση στη cache που θα ψάξουμε Το tag (ετικέτα) συγκρίνεται με αυτό που φυλάσσεται στην

cache μαζί με τα δεδομένα

Δεδομένα (block 4 bytes)

Ετικέτα/tag(Διεύθυνση)

Μνήμη Cache0000 00

1111 00

0111 00

01

00011011

Διεύθυνση block

TAG INDEX BLOCK

Ζητούμενη διεύθυνση

01 11 0011 11 10


Direct mapped

• 1-1 αντιστοιχία block μνήμης σε θέση στην cache

Block Placement: direct-mapped

Μνήμη Direct mapped0000

1111

0111


Set associative (n-way): • 1-n αντιστοιχία block μνήμης σε θέσεις στην cache• To index διαλέγει ένα ολόκληρο set• Πρέπει να συγκρίνουμε με όλα τα tags στο set για να

βρούμε αν κάτι είναι στην cache• Καλύτερο Hit Rate, πιο αργή στην προσπέλαση

Block Placement: set-associative

Μνήμη2-way Set associative

0000

1111

0111

TAG INDEX BLOCK

Ζητούμενη διεύθυνση:

01 11 0011 11 00

00011011

01 11

00 11 00

0011

Way-0 Way-1


Αντικατάσταση

• Tυχαία (Random)

— πολύ εύκολη υλοποίηση

— αποδεκτή απόδοση

• LRU (Pseudo-LRU): Least Recently Used, λιγότερο πρόσφατο

— δύσκολη υλοποίηση

— καλύτερη απόδοση

— Pseudo-LRU: συμβιβασμός

• FIFO: First-In First-Out 2 με 4 way η καλύτερη απόδοση

• πιο πολλά way: πολύ μικρή αύξηση στην απόδοση με μεγάλο κόστος

Block Replacement: set-associative


Write-through

• Κάθε φορά που γράφουμε σε ένα block της cache στέλνουμε τα νέα δεδομένα και στη μνήμη

Write-back

• Νέα δεδομένα που γράφονται στην cache δεν στέλνονται στη μνήμη αμέσως αλλά μόνο αν αντικατασταθεί το block

• Πολλαπλές εγγραφές στο block χρειάζονται μόνο μια μεταφορά στην μνήμη

• Τα περιεχόμενα της μνήμης και της cache ΔΕΝ είναι ιδια Cache Consistency problem => I/O, multiprocessing κλπ.

— Αντιμετωπίζεται σαν μέρος του Cache Coherency Protocol (MESI) για multiprocessing

• Χρειάζεται ένα επιπλέον bit το “dirty bit” σε κάθε block που υποδηλώνει εάν το block έχει αλλάξει

Write Strategy: write-trough vs. write-back


Cache Performance

CPUtime = Instruction Count x (CPIexecution + Mem accesses per instruction x Miss rate x Miss penalty) x Clock cycle time

Misses per instruction = Memory accesses per instruction x Miss rate

CPUtime = IC x (CPIexecution + Misses per instruction x Miss penalty) x Clock cycle time


Improving Cache Performance

1. Reduce the miss rate,

2. Reduce the miss penalty, or

3. Reduce the time to hit in the cache.


Reducing Misses

Classifying Misses: 3 Cs

• Compulsory—The first access to a block is not in the cache, so the block must be brought into the cache. Also called cold start misses or first reference misses.(Misses in even an Infinite Cache)

• Capacity—If the cache cannot contain all the blocks needed during execution of a program, capacity misses will occur due to blocks being discarded and later retrieved.(Misses in Fully Associative Size X Cache)

• Conflict—If block-placement strategy is set associative or direct mapped, conflict misses (in addition to compulsory & capacity misses) will occur because a block can be discarded and later retrieved if too many blocks map to its set. Also called collision misses or interference misses.(Misses in N-way Associative, Size X Cache)


Cache Size (KB)

Mis

s R

ate

per

Typ

e

0

0.02

0.04

0.06

0.08

0.1

0.12

0.141 2 4 8

16

32

64

12

8

1-way

2-way

4-way

8-way

Capacity

Compulsory

3Cs Absolute Miss Rate (SPEC92)

Conflict

Compulsory vanishinglysmall


Cache Size (KB)

Mis

s R

ate

per

Typ

e

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

1 2 4 8

16

32

64

12

8

1-way

2-way

4-way

8-way

Capacity

Compulsory

2:1 Cache Rule

Conflict

miss rate 1-way associative cache size X = miss rate 2-way associative cache size X/2


How Can Reduce Misses?

3 Cs: Compulsory, Capacity, Conflict In all cases, assume total cache size not changed:What happens if:1) Change Block Size:

Which of 3Cs is obviously affected?

2) Change Associativity: Which of 3Cs is obviously affected?

3) Change Compiler: Which of 3Cs is obviously affected?


Block Size (bytes)

Miss Rate

0%

5%

10%

15%

20%

25%

16

32

64

12

8

25

6

1K

4K

16K

64K

256K

1. Reduce Misses via Larger Block Size


2. Reduce Misses via Higher Associativity

2:1 Cache Rule:

•Miss Rate DM cache size N Miss Rate 2-way cache size N/2

Beware: Execution time is only final measure!

•Will Clock Cycle time increase?

•Hill [1988] suggested hit time for 2-way vs. 1-way external cache +10%, internal + 2%


3. Reducing Misses via a“Victim Cache”

How to combine fast hit time of direct mapped yet still avoid conflict misses?

Add buffer to place data discarded from cache

Jouppi [1990]: 4-entry victim cache removed 20% to 95% of conflicts for a 4 KB direct mapped data cache

Used in Alpha, HP machines


How to combine fast hit time of Direct Mapped and have the lower conflict misses of 2-way SA cache?

Divide cache: on a miss, check other half of cache to see if there, if so have a pseudo-hit (slow hit)

Drawback: CPU pipeline is hard if hit takes 1 or 2 cycles

• Better for caches not tied directly to processor (L2)

• Used in MIPS R1000 L2 cache, similar in UltraSPARC

4. Reducing Misses via “Pseudo-Associativity”

Hit Time

Pseudo Hit Time Miss Penalty

Time


Prefetching: μεταφορά block από την μνήμη στην cache πριν αυτά ζητηθούν από τον επεξεργαστή

• Χρειάζονται περισσότερο bandwidth αλλά μπορεί να μειώσουν το latency

• Οταν είναι λάθος μπορεί να κάνουν μεγάλη ζημιά: όχι μόνο καταναλώνουν bandwidth αλλά μπορεί να εκτοπίσουν χρήσιμα δεδομένα από την cache

Πως γίνεται ?

• Software, MIPS 10K

• Hardware: πάρα πολλά σχήματα απλά … πολύ πολύπλοκα

— sequential prefetch (block i, prefetch i+1)

— stream buffers (ανακαλύπτουν ακολουθίες από block)

— correlating prefetchers (πρόβλεψη με ιστορία)

5: Hardware prefetching


Το πιο πετυχημένο σχήμα μέχρι στιγμής: Hu, Καξίρας, Martonosi, ISCA 2002

Correlating prefetcher με πρόβλεψη χρόνου

• Διατηρεί ιστορία από ακολουθείες tag που εμφανίζονται στη cache:

• Αν δούμε A,B κάνουμε prefetch to C

• Προβλέπουμε επίσης πόσο θα μείνει το B στην cache ώστε να κάνουμε prefetch το C μετά τη “ζωή” του B

• Με 8ΚΒ ιστορία ελαχιστοποιούμε το miss rate μιας 32KB L1D σχεδόν όσο είναι θεωρητικά δυνατό

5: Hardware prefetching

...,A,B,C,..

...,D,B,C,..

...,C,A,B,C.

...,E,F,G,..

ABCDBCCABEFG

Πίνακας Ιστορίας

Μνήμη Cache

Ακολουθίες TAG


6. Reducing Misses by Software Prefetching Data

Data Prefetch

• Load data into register (HP PA-RISC loads)

• Cache Prefetch: load into cache (MIPS IV, PowerPC, SPARC v. 9)

• Special prefetching instructions cannot cause faults;a form of speculative execution

Issuing Prefetch Instructions takes time

• Is cost of prefetch issues < savings in reduced misses?

• Higher superscalar reduces difficulty of issue bandwidth


7. Reducing Misses by Compiler Optimizations

McFarling [1989] reduced caches misses by 75% on 8KB direct mapped cache, 4 byte blocks in software

Instructions

• Reorder procedures in memory so as to reduce conflict misses

• Profiling to look at conflicts(using tools they developed) Data

• Merging Arrays: improve spatial locality by single array of compound elements vs. 2 arrays

• Loop Interchange: change nesting of loops to access data in order stored in memory

• Loop Fusion: Combine 2 independent loops that have same looping and some variables overlap

• Blocking: Improve temporal locality by accessing “blocks” of data repeatedly vs. going down whole columns or rows


Performance Improvement

1 1.5 2 2.5 3

compress

cholesky(nasa7)

spice

mxm (nasa7)

btrix (nasa7)

tomcatv

gmty (nasa7)

vpenta (nasa7)

mergedarrays

loopinterchange

loop fusion blocking

Summary of Compiler Optimizations to Reduce Cache Misses (by hand)


Summary

3 Cs: Compulsory, Capacity, Conflict


2. Reduce Misses via Higher Associativity

3. Reducing Misses via Victim Cache

4. Reducing Misses via Pseudo-Associativity

5. Reducing Misses by HW Prefetching Instr, Data

6. Reducing Misses by SW Prefetching Data

7. Reducing Misses by Compiler Optimizations Remember danger of concentrating on just one

parameter when evaluating performance

CPUtimeIC CPIExecution

Memory accesses

InstructionMiss rateMiss penalty

Clock cycle time


Review: Improving Cache Performance





1. Reduce Miss Penalty: Subblock Placement

Don’t have to load full block on a missHave valid bits per subblock to indicate valid(Originally invented to reduce tag storage)

Valid Bits Subblocks


2. Reduce Miss Penalty: Early Restart and Critical Word First

Don’t wait for full block to be loaded before restarting CPU

• Early restart—As soon as the requested word of the block arrives, send it to the CPU and let the CPU continue execution

• Critical Word First—Request the missed word first from memory and send it to the CPU as soon as it arrives; let the CPU continue execution while filling the rest of the words in the block. Also called wrapped fetch and requested word first

Generally useful only in large blocks, Spatial locality a problem; tend to want next sequential

word, so not clear if benefit by early restart

block


Γιά Superscalar και OOO χρειάζεται να εκτελούμε πολλά loads ταυτόχρονα (stores υπάρχει store buffer)

• Οι σύγχρονες cache έχουν πολλαπλά ports και μπορούν να εξυπηρετήσουν πολλά Hits ταυτόχρονα

Τι γίνεται όμως όταν έχουμε πολλαπλά miss ?

• Εάν η cache μπορεί να εξυπηρετήσει μόνο ένα miss τη φορά ( Blocking ) τότε τα load εκτελούνται το ένα μετά το άλλο με μεγάλη καθυστέρηση

3. Reduce Miss Penalty: Non-blocking Cache

Load A Load B Load C Load D

miss miss miss miss

time


Λύση ? Non-blocking caches: εξυπηρετούν ταυτόχρονα πολλαπλά miss. PIPELINING για τα miss

To status κάθε miss ελέγχεται από ένα MSHR (miss-status handling register)

3. Reduce Miss Penalty: Non-blocking Cache

Load A

Load B

Load C

Load D

miss

miss

miss

miss

time


3. Reduce Miss Penalty: Non-blocking Caches

“hit under miss” reduces the effective miss penalty by working during miss vs. ignoring CPU requests

“hit under multiple miss” or “miss under miss” may further lower the effective miss penalty by overlapping multiple misses

• Significantly increases the complexity of the cache controller as there can be multiple outstanding memory accesses

• Requires muliple memory banks (otherwise cannot support)

• Penium Pro allows 4 outstanding memory misses


Value of Hit Under Miss for SPEC

FP programs on average: AMAT= 0.68 -> 0.52 -> 0.34 -> 0.26

Int programs on average: AMAT= 0.24 -> 0.20 -> 0.19 -> 0.19

8 KB Data Cache, Direct Mapped, 32B block, 16 cycle miss

Hit Under i Misses

Av

g.

Me

m.

Acce

ss T

ime

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

eqnto

tt

esp

ress

o

xlisp

com

pre

ss

mdljsp

2

ear

fpppp

tom

catv

swm

256

doduc

su2co

r

wave5

mdljdp2

hydro

2d

alv

inn

nasa

7

spic

e2g6

ora

0->1

1->2

2->64

Base

Integer Floating Point

“Hit under n Misses”

0->11->22->64Base


Reducing Miss penalty: L2 Cache

Reducing L2 Miss Rate


2. Reduce Conflict Misses via Higher Associativity

3. Reducing Conflict Misses via Victim Cache

4. Reducing Conflict Misses via Pseudo-Associativity

5. Reducing Misses by HW Prefetching Instr, Data

6. Reducing Misses by SW Prefetching Data

7. Reducing Capacity/Conf. Misses by Compiler Optimizations


Relative CPU Time

Block Size

11.11.21.31.41.51.61.71.81.9

2

16 32 64 128 256 512

1.361.28 1.27

1.34

1.54

1.95

L2 cache block size & A.M.A.T.

32KB L1, 8 byte path to memory


Reducing Miss Penalty Summary

Four techniques

• Subblock placement

• Early Restart and Critical Word First on miss

• Non-blocking Caches (Hit under Miss, Miss under Miss)

• Second Level Cache

CPUtimeIC CPIExecution

Memory accesses

InstructionMiss rateMiss penalty

Clock cycle time


Cache Optimization Summary

Technique MR MP HT Complexity

Larger Block Size + – 0Higher Associativity + – 1Victim Caches + 2Pseudo-Associative Caches + 2HW Prefetching of Instr/Data + 2Compiler Controlled Prefetching + 3Compiler Reduce Misses + 0

Priority to Read Misses + 1Subblock Placement + + 1Early Restart & Critical Word 1st + 2Non-Blocking Caches + 3Second Level Caches + 2

mis

s r

ate

mis

s p

en

alty


Improving Cache Performance





1. Fast Hit times via Small and Simple Caches

Why Alpha 21164 has 8KB Instruction and 8KB data cache + 96KB second level cache?

•Small data cache and clock rateDirect Mapped, on chip


2. Fast hits by Avoiding Address Translation

Send virtual address to cache? Called Virtually Addressed Cache or just Virtual Cache vs. Physical Cache

• Every time process is switched logically must flush the cache; otherwise get false hits

—Cost is time to flush + “compulsory” misses from empty cache

• Dealing with aliases (sometimes called synonyms); Two different virtual addresses map to same physical address

• I/O must interact with cache, so need virtual address Solution to aliases

• HW guarantees covers index field & direct mapped, they must be unique;called page coloring

Solution to cache flush

• Add process identifier tag that identifies process as well as address within process: can’t get a hit if wrong process


Virtually Addressed Caches

CPU

TB

$

MEM

VA

PA

PA

ConventionalOrganization

CPU

$

TB

MEM

VA

VA

PA

Virtually Addressed CacheTranslate only on miss

Synonym Problem

CPU

$ TB

MEM

VA

PATags

PA

Overlap $ accesswith VA translation:requires $ index to

remain invariantacross translation

VATags

L2 $


2. Fast Cache Hits by Avoiding Translation: Process ID impact

Black is uniprocessLight Gray is multiprocess when

flush cacheDark Gray is multiprocess when use

Process ID tagY axis: Miss Rates up to 20%X axis: Cache size from 2 KB to

1024 KB


2. Fast Cache Hits by Avoiding Translation : Index with Physical Portion of Address

If index is physical part of address, can start tag access in parallel with translation so that can compare to physical tag

Limits cache to page size: what if want bigger caches and uses same trick?

•Higher associativity moves barrier to right

•Page coloring

Page Address Page Offset

Address Tag Index Block Offset


Cache Optimization Summary

Technique MR MP HT Complexity

Larger Block Size + – 0Higher Associativity + – 1Victim Caches + 2Pseudo-Associative Caches + 2HW Prefetching of Instr/Data + 2Compiler Controlled Prefetching + 3Compiler Reduce Misses + 0

Priority to Read Misses + 1Subblock Placement + + 1Early Restart & Critical Word 1st + 2Non-Blocking Caches + 3Second Level Caches + 2

Small & Simple Caches – + 0Avoiding Address Translation + 2Pipelining Writes + 1

mis

s ra

teh

it t

ime

mis

sp

enal

ty


Ιεραρχία Μνήμης στους x86

80386 εξωτερική, unified, direct-mapped, 32ΚΒ 80486 εξωτερική, unified, direct-mapped, 64KB Pentium

L1 Instruction8KB, 2-way LRU,

32B/line

L1 Data8KB, 2-way LRU, 32B/line, 2-ports

L2 Unified64-256KB, direct mapped,

32B/line



Pentium Pro

L1 Instruction8KB, 4-way LRU,

32B/line

L1 Data8KB, 2-way LRU,

32B/line, 2-ports,8 banks

L2 Unified256KB-1MB, 4-way,

32B/linenon-blocking

εσωτερική/εξωτερική



Pentium 4

L1 InstructionTRACE CACHE

12ΚμOP, 8-way LRU, 6-μOPs/line

(across branches)

L1 Data8KB, 4-way LRU, 64B/line, 2-ports,

Write-troughNon-blocking (4 misses)

2/6 Cycle latency (Integer/FP)16 byte bus to FP

L2 Unified128KB 2-way, 256KB 4-way, 512 8-way

Pseudo-LRU, 64B/linenon-blocking

7/7 Cycle Latency (Integer/FP),256 Bit Bus, Data on every Cycle

L3-Unified: 512KB, 4-Way, 1024KB, 8-Way, 64 Byte/Line


Το “καυτό” πρόβλημα της αρχιτεκτονικής σήμερα

• Intel CTO Pat Gelsinger: “πυκνότητα ισχύος” σε επεξεργαστές αυξάνεται εκθετικά

Δυναμική ισχύς (λειτουργία τρανζίστορ, ~90%), στατική ισχύς (ρεύματα διαρροής, ~10%)

• Για να μειώσουμε τη δυναμική ισχύ μειώνουμε την τάση τροφοδοσίας (Vdd) => εκθετική αύξηση της στατικής κατανάλωσης ισχύος

Andy Grove (13/12/2002) : Το τέλος του νόμου του Moore!

• Λιθογραφία? Κβαντικά φαινόμενα? Κόστος εργοστασίων?

• Ρεύματα διαρροής

Κατανάλωση Ισχύος


CACHE DECAY: Καξίρας, Hu, Martonosi, ISCA 2001 Διακοπή τάσης τροφοδοσίας σε γραμμές της cache που δεν

πρόκειται να χρησιμοποιηθούν ξανά

• Temporal Locality: Ότι προσπελάστηκε πρόσφατα είναι πιθανό να προσπελαστεί ξανά

• Ότι δεν έχει προσπελαστεί εδώ και πολύ ώρα είναι απίθανο να προσπελαστεί ξανά

Μέθοδο να μετράμε χρόνο μεταξύ προσπελάσεων Μπορούμε να “σβήσουμε” το 80% της cache (L1) χωρίς

σχεδόν καμία επίπτωση στην απόδοση (L2 καλύτερα)

• δεν σημαίνει ότι μια μικρή cache δουλεύει το ίδιο καλά …

5x μείωση κατανάλωσης στατικής ισχύος (αμελητέα αύξηση στη δυναμική ισχύ)

Κατανάλωση Στατικής Ισχύος και μνήμες cache

Περιεχόμενα

Documents

Transcript of Περιεχόμενα