Pipeline‐Stall als Lösung

(1)

Nicht auflösbare Data‐Hazards

Nicht jeder Data‐Hazard lässt sich durch Forwarding

auflösen. Beispiel: Zugriff auf vorher gelesenes Register.

Bildquelle: David A. Patterson und John L. Hennessy, „Computer Organization and Design“, Fourth Edition, 2012

(2)

Pipeline‐Stall als Lösung

(3)

Allgemeine Lösung mittels Hazard‐Detection‐Unit

(4)

Implementation der Hazard‐Detection‐Unit

(5)

Quiz: Vermeiden von Pipeline‐Stalls

lw $t1, 0($t0) lw $t2, 4($t0)

add $t3, $t1, $t2 sw $t3, 12($t0) lw $t4, 8($t0)

add $t5, $t1, $t4 sw $t5, 16($t0)

Wo findet ein Pipe‐

line‐Stall statt? Bitte ankreuzen.

Bitte Befehle umorganisie‐

ren, sodass alle Stalls vermieden werden.

Anzahl Taktzyklen mit Stalls?

Anzahl Taktzyklen ohne Stalls?

(6)

Control‐Hazards

(7)

Control‐Hazards

(8)

Branch‐Not‐Taken‐Strategie und Pipeline‐Flush

Flush = Verwerfe Instruktionen in der Pipeline. Hier: Setze IF/ID‐, ID/EX‐ und

EX/MEM‐Register auf 0.

(9)

Reduktion des Branch‐Delays

• Adressberechnung kann schon in der ID‐Stufe stattfinden

• beq und bne erfordert lediglich ein 32‐Bit‐XOR und ein 32‐Bit‐OR

– Dazu braucht man keine ALU

– Also auch in der ID‐Stufe realisierbar

• Damit ist der Sprung schon in der ID‐

Stufe entschieden

Beispiel: für $1 und $3:

(10)

Reduktion des Branch‐Delays

• Konsequenz

– Branch‐Delay ist damit ein Instruktions‐Zyklus

– Wir brauchen lediglich ein Flush‐IF/ID‐Register

(11)

Reduktion des Branch‐Delays

• Achtung!

– Forwarding aus späteren Stufen macht die Sache kompliziert.

– Kann Pipeline‐Stall aufgrund von Data‐Hazards erforderlich

machen.

• z.B. ein Zyklus, wenn ALU‐Ergebins in den Vergleich einfließt

• z.B. zwei Zyklen, wenn

Vergleichsoperator einen Schritt vorher aus dem Speicher geladen wurde

– Betrachten wir aber hier nicht genauer.

(12)

Dynamic‐Branch‐Prediction‐Strategie

Unterer Teil der Adresse

Branch hat stattgefunden

0x00 1

0x04 0

0x08 1

...

0xf8 0

0xfc 0

Branch‐Prediction‐Buffer 0x400000 : lw $1, 0($4)

0x400004 : beq $1, $0, 40 0x400008 : add $1, $1, $1 0x40000c : ...

...

0x40c004 : bne $3, $4, 120

...

(13)

Vorhersagegenauigkeit

Annahme unendlich langer Loop, der immer 9 mal und dann einmal nicht durchlaufen wird. Was ist die

Vorhersagegenauigkeit der vorher beschriebenen Branch‐Prediction?

Lässt sich das Verbessern?

loop: ...

...

bne $1,$2,loop ...

j loop

(14)

N‐Bit‐Vorhersage am Beispiel 2‐Bit

(15)

Vorhersagegenauigkeit

Annahme unendlich langer Loop, der immer 9 mal und dann einmal nicht durchlaufen wird. Was ist die

Vorhersagegenauigkeit der vorher beschriebenen 2‐Bit‐Branch‐

Prediction?

loop: ...

...

bne $1,$2,loop ...

j loop

(16)

Branch‐Delay‐Slot‐Idee

loop: ...

...

bne $1,$2,loop

<instruktion>

• Wird immer ausgeführt.

• Instruktion muss aber unabhängig von der Branch‐Entscheidung sein.

• Das muss der Compiler entscheiden.

• Im Zweifelsfall: nop passt immer.

(17)

Beispiele von Branch‐Delay‐Slot‐Schedules

(18)

Weniger Branches mit Conditional‐Instruktionen

Beispiel MIPS‐Instruktionen movn und movz :

movn $8, $11, $4 # $8 = $11, wenn $4 != 0 movz $8, $11, $4 # $8 = $11, wenn $4 == 0 Erinnerung ARM‐ISA:

ADDEQ r0,r1,r2 ; If zero flag set then…

; ... r0 = r1 + r2

(19)

Quiz

Betrachte die folgenden Branch‐Strategien:

1. Vorhersage Branch findet statt

2. Vorhersage Branch findet nicht statt

3. Dynamische Branch‐Vorhersage (mit 90% Genauigkeit) Was ist die beste Strategie, wenn:

• Branch findet mit 5% Häufigkeit statt?

• Branch findet mit 95% Häufigkeit statt?

• Branch findet mit 70% Häufigkeit statt?

(20)

Multiple‐Issue

(21)

Motivation

• Bisher: Instruction‐Level‐Parallelism (ILP) durch Pipelining

– ILP kann durch Pipeline‐Stufe erhöht werden

– Pipelines mit mehr Stufen sind anfälliger gegenüber Data‐ und Control‐

Hazards

– Also: Pipeline‐Stufen nur bis zu gewisser Tiefe sinnvoll – Außerdem: Grenzen aufgrund der Leistungsaufnahme

– CPI bleibt gleich oder steigt sogar (wegen Hazards), Clock‐Rate steigt

• Hier eine weitere Methode um ILP zu steigern: Multiple‐Issue

– Replikation von internen CPU‐Strukturen, sodass mehrere Instruktionen pro Pipeline‐Stufe möglich sind

– CPI sinkt und Clock‐Rate bleibt gleich (oder sinkt sogar wegen erhöhter Komplexität)

– Beispiel: CPI eines 4‐Wege‐Multiple‐Issue‐Mikroprozessor hat eine ideale CPI von? 0.25!

– CPI liegt aber in der Regel höher, wie wir gleich sehen werden

• Wir unterscheiden zwischen:

– Static‐Multiple‐Issue: Entscheidungen werden zur Compile‐Zeit gefällt – Dynamic‐Multiple‐Issue: Entscheidungen werden zur Laufzeit gefällt

(auch Superskalare CPU bezeichnet)

(22)

Multiple‐Issue

Static‐Multiple‐Issue

(23)

Generelle Idee

• Eine große Instruktion pro Clock‐Cycle

• Große Instruktion besteht aus mehreren gleichzeitig stattfindenden Operationen

• Aber nicht jede Kombination von Operationen möglich

• Beispiel:

– ALU‐Operation und Speicheroperation gleichzeitig möglich

– Aber zwei ALU‐Operation auf einmal nicht möglich

• Terminologie: VLIW (Very Long Instruction Word)

(24)

Beispiel am MIPS‐Datenpfad

Extra ALU für gleichzeitige Adresskalkulation

ALU für arithmetische

Operationen

(25)

Statische Two‐Issue Pipeline im Betrieb

Was ist der CPI‐Wert?

(26)

Was ist nun die Aufgabe des Compilers?

Loop: lw $t0, 0($s1) # $t0=Array-Element addu $t0, $t0, $s2 # addiere Wert

sw $t0, 0($s1) # Speichere Element addi $s1, $s1, -4 # nächstes Element bne $s1, $zero, Loop # solange $s1 != 0 Compiler erzeugt Assembler‐Code:

und ordnet Instruktionen so an, dass keine Pipeline‐Stalls entstehen

Was ist der CPI‐Wert?

(27)

Verbesserung: Loop‐Unrolling

Loop: lw $t0, 0($s1) # $t0=Array-Element addu $t0, $t0, $s2 # addiere Wert

sw $t0, 0($s1) # Speichere Element addi $s1, $s1, -4 # nächstes Element bne $s1, $zero, Loop # solange $s1 != 0 Code wie vorher (der Einfachheit sei Loop‐Index Vielfaches von 4):

Loop‐Body vier mal kopiert und Register‐Renaming

Was ist der CPI‐Wert?

(28)

Multiple‐Issue

Dynamic‐Multiple‐Issue

(29)

Generelle‐Idee

• CPU entscheidet, ob und wie viele aufeinander folgende Instruktionen parallel gestartet werden können

• Compiler erzeugt nur eine Folge von Instruktionen; kein VLIW

• Instruktions‐Scheduling des Compilers nicht mehr erforderlich aber trotzdem aus Performance‐

Gründen sinnvoll

• Verbesserung der Superskalarität durch dynamisches Pipeline‐Scheduling:

Instruktionsreihenfolge darf geändert werden, um

Stalls zu vermeiden

(30)

Dynamic‐Pipeline‐Scheduling Motivation

lw $t0, 20($s2) # zunächst $t0 laden

addu $t1, $t0, $t2 # addu durch lw verzögert sub $s4, $s4, $t3 # sub könnte schon starten slti $t5, $s4, 20 # und genau so auch slti

Warum nicht sub (und ggf. slti) vor addu vorziehen?

(31)

Dynamic‐Pipeline‐Scheduling generell

(32)

Wiedervorlage: Daten einiger ausgewählter Prozessoren

(33)

Zusammenfassung und Literatur

(34)

Zusammenfassung

• Schlechte Performance von Single‐Cylce‐Ansatz

• Instruktionsabarbeitung besteht aus mehreren Zyklen

• Moderne Prozessoren nutzen dies für – Pipelining

– Multiple‐Issue

• Allgemein als Instruction‐Level‐Parallelism bezeichnet

• Für High‐Level‐Programmierer ist die Parallelität nicht sichtbar – Sichtbar auf Assmbler‐Ebene

– Sichtbar auch Compiler‐Ebene

• Haupt‐Probleme die die Parallelität einschränken – Daten‐Abhängigkeiten