Post on 05-Oct-2020
Dana K. Urribarri AC 2016 1
Arquitectura de Computadoraspara Ingeniería
(Cód. 7526)1° Cuatrimestre 2016
Dra. Dana K. UrribarriDCIC - UNS
Dana K. Urribarri AC 2016 2
Pipelining
Dana K. Urribarri AC 2016 3
Clasificación de los pipelineDe acuerdo a su nivel de procesamiento● Pipeline aritmético:
– Las operaciones aritméticas se segmentan para permitir el procesamiento en pipeline.
● Pipeline de instrucciones:– Las instrucciones se procesan en pipeline,
permitiendo el solapamiento.
● Pipeline de procesadores: – Procesadores en cascada procesan el mismo flujo de
datos. Cada uno realiza una tarea específica.
Dana K. Urribarri AC 2016 4
Clasificación de los pipelineDe acuerdo a su configuración y estrategia de control● Unifuncional vs. Multifuncional:
– Un pipeline unifuncional realiza una única tarea fija.
– Un pipeline multifuncional puede realizar varias tareas diferentes, en simultáneo o no.
● Estático vs. Dinámico:– Un pipeline estático asume una única configuración por vez. Un pipeline
unifuncional es estático.
– Un pipeline dinámico permite varias configuraciones en simultáneo. Un pipeline dinámico es multifuncional.
● Escalar vs. Vectorial:– Un pipeline escalar procesa operandos escalares (enteros, punto flotante o
valor lógico).
– Un pipeline vectorial procesa instrucciones vectoriales sobre operandos vectoriales.
Dana K. Urribarri AC 2016 5
Pipeline de instrucciones
Dana K. Urribarri AC 2016 6
Diseño de la microarquitectura● Tres posibles microarquitecturas para MIPS:
– Diseño único ciclo:
Ejecuta la instrucción completa en un único ciclo.
– Diseño multi-ciclo:
Ejecuta las instrucciones en una serie de ciclos cortos.
– Diseño en pipeline:
Aplica pipeline a la microarquitectura de un único ciclo.
Dana K. Urribarri AC 2016 7
Microarquitectura único ciclo
SignImm
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PC0
1PC' Instr
25:21
20:16
15:0
5:0
SrcB
20:16
15:11
<<2
+
ALUResult ReadData
WriteData
SrcA
PCPlus4
PCBranch
WriteReg4:0
Result
31:26
RegDst
Branch
MemWrite
MemtoReg
ALUSrc
RegWrite
Op
Funct
ControlUnit
Zero
PCSrc
CLK
ALUControl2:0
ALU
Dana K. Urribarri AC 2016 8
Microarquitectura en pipeline● Se divide la microarquitectura único ciclo en 5
etapas.● Pueden haber 5 instrucciones ejecutando
simultáneamente.● Idealmente, la lógica de cada etapa es 1/5 de la
lógica total.– La frecuencia del reloj puede ser 5 veces mayor.
● Si bien la latencia de cada instrucción es la (≈) misma, el throughput es 5 veces mayor.
Dana K. Urribarri AC 2016 9
Microarquitectura en pipeline● Las tareas con más retardos son:
– Lecturas y escrituras en memoria
– Operaciones en la ALU
● Las 5 etapas del pipeline se diseñan de forma que cada una involucre sólo una de esas tareas.1) Instruction fetch → Lectura en memoria
2) Instruction decode → Lectura de registros
3) Execution → ALU
4) Memory access → Lectura/escritura en memoria
5) Writeback → Escritura de registros
Dana K. Urribarri AC 2016 10
Microarquitectura en pipeline1) Instruction fetch (IF). Se trae de memoria la instrucción en
la posición indicada por el PC. Se asume que la instrucción no es un branch y se incrementa el PC.
2) Instruction decode (ID). Se decodifica la instrucción y se reconoce su tipo. Se buscan los operandos.
3) Execution (EX). Se ejecuta la instrucción. Difiere si es una operación aritmética, un acceso a memoria o un branch.
4) Memory access (Mem). Se accede efectivamente a la memoria en caso de que la instrucción sea un acceso a memoria.
5) Writeback (WB). Si la instrucción no es un branch o un store, el resultado de la operación (o del load) se almacena en el registro resultado.
Dana K. Urribarri AC 2016 11
Abstracción del pipeline
Registros interetapas.Almacenan la información necesariapara comenzar con la siguiente etapa.
Dana K. Urribarri AC 2016 12
Datapath único ciclo & en pipeline
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PCF0
1PC' InstrD
25:21
20:16
15:0
SrcBE
20:16
15:11
RtE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchM
ResultW
PCPlus4EPCPlus4F
ZeroM
CLK CLK
ALU
WriteRegE4:0
CLK
CLK
CLK
SignImm
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PC0
1PC' Instr
25:21
20:16
15:0
SrcB
20:16
15:11
<<2
+
ALUResult ReadData
WriteData
SrcA
PCPlus4
PCBranch
WriteReg4:0
Result
Zero
CLK
ALU
Fetch Decode Execute Memory Writeback
Dana K. Urribarri AC 2016 13
Datapath en pipeline corregidoLa señal de escritura en registros debe llegar junto con el dato.
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PCF0
1PC' InstrD
25:21
20:16
15:0
SrcBE
20:16
15:11
RtE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchM
WriteRegM4:0
ResultW
PCPlus4EPCPlus4F
ZeroM
CLK CLK
WriteRegW4:0
ALU
WriteRegE4:0
CLK
CLK
CLK
Fetch Decode Execute Memory Writeback
Dana K. Urribarri AC 2016 14
Datapath & control del pipeline
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PCF0
1PC' InstrD
25:21
20:16
15:0
5:0
SrcBE
20:16
15:11
RtE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchM
WriteRegM4:0
ResultW
PCPlus4EPCPlus4F
31:26
RegDstD
BranchD
MemWriteD
MemtoRegD
ALUControlD
ALUSrcD
RegWriteD
Op
Funct
ControlUnit
ZeroM
PCSrcM
CLK CLK CLK
CLK CLK
WriteRegW4:0
ALUControlE2:0
ALU
RegWriteE RegWriteM RegWriteW
MemtoRegE MemtoRegM MemtoRegW
MemWriteE MemWriteM
BranchE BranchM
RegDstE
ALUSrcE
WriteRegE4:0
IF/IDFD
ID/EXDE
EX/MEMEM
MEM/WBMW
Dana K. Urribarri AC 2016 15
Superposición de etapas● Si asumimos que acceder a memoria de datos e
instrucciones es lo que más demora.– Las etapas no demoran exactamente lo mismo,
aumenta la latencia de cada instrucción.
Las 5 etapas ejecutando a la vez.Las etapas no pueden compartir hardware.
Dana K. Urribarri AC 2016 16
Requerimientos de hardware● Para superponer Fetch y Memory
– Memorias (cache) separadas para instrucciones y datos.
● Para superponer Fetch y Execute– Dos ALUs. Una para incrementar el PC y otra para
ejecutar la instrucción.
● Para superponer WriteBack y Decode– Los registros se escriben en la primera mitad del ciclo
y se leen en la segunda.
Dana K. Urribarri AC 2016 17
Uso de las etapas del pipeline
● Dependiendo de la instrucción, algunas etapas pueden estar ociosas.
● Todas involucran Fetch → Decode → Execute
Time (cycles)
lw $s2, 40($0) RF 40
$0RF
$s2+ DM
RF $t2
$t1RF
$s3+ DM
RF $s5
$s1RF
$s4- DM
RF $t6
$t5RF
$s5& DM
RF 20
$s1RF
$s6+ DM
RF $t4
$t3RF
$s7| DM
add $s3, $t1, $t2
sub $s4, $s1, $s5
and $s5, $t5, $t6
sw $s6, 20($s1)
or $s7, $t3, $t4
1 2 3 4 5 6 7 8 9 10
add
IM
IM
IM
IM
IM
IMlw
sub
and
sw
or
$s6
Dana K. Urribarri AC 2016 18
Conflictos● En condiciones ideales, el pipeline termina una
instrucción por ciclo.● Las condiciones no siempre son ideales:
– conflictos (hazards)
● Los conflictos se detectan en la etapa de decode.
Dana K. Urribarri AC 2016 19
Tipos de conflictos● Estructurales:
– La instrucción necesita de un recurso que está ocupado.
● De datos:– La ejecución de una instrucción depende de la ejecución
de una instrucción previa y ambas instrucciones están concurrentemente ejecutándose en el pipeline.
● De control:– Dado que el PC se incrementa en cada ciclo, el pipeline
funciona bien cuando no hay cambios en el flujo secuencial de las instrucciones (branch, jump, call, return)
Dana K. Urribarri AC 2016 20
Conflictos estructurales● La instrucción necesita de un recurso que está
ocupado.● Soluciones:
– Duplicar el recurso
– Implementar la unidad en pipeline
– Cola de esperas a la unidad funcional (D-virtuales)
Dana K. Urribarri AC 2016 21
Conflictos de datos● La ejecución concurrente debe coincidir con la
ejecución secuencial. (i < j)● Read after Write (RAW)
Si la instrucción j lee su dato fuente antes de que la instrucción i lo escriba, j operaría con un valor incorrecto.
● Write after Read (WAR)La instrucción j escribe el dato antes de que la instrucción i lo lea.
● Write after Write (WAW)Dos instrucciones tienen el mismo registro de salida
Dana K. Urribarri AC 2016 22
Write after Read (antidependiencia)
– i : R7 ← R12 + R15
– i+1 : R15 ← R7 – R12
i+1 : R15 ← R7 – R12
R15 se necesita acá
i : R7 ← R12 + R15
R15 se escribe acá
Conflictos de datos
Dana K. Urribarri AC 2016 23
Write after Write– i : R7 ← R12 + R15
– i+1 : R7 ← R4 – R12
i+1 : R7 ← R4 – R12
R7 se escribe acá
i : R7 ← R12 + R15
R7 se vuelve aescribir acá
Conflictos de datos
Dana K. Urribarri AC 2016 24
Read after Write– i : R7 ← R12 + R15
– i+1 : R15 ← R7 – R12
i+1 : R15 ← R7 – R12
Escribe R7
i : R7 ← R12 + R15
Se necesita R7
Conflictos de datos
Dana K. Urribarri AC 2016 25
Conflictos en el pipeline● En la implementación simple del pipeline la
ejecución es en orden y todas las etapas demoran lo mismo. Por lo tanto evita:– Conflictos estructurales
– Conflictos de datos● WAR● WAW
● Solamente tenemos conflictos:– RAW → Dependencia de procedimiento
– De control
Dana K. Urribarri AC 2016 26
Gestión de los conflictos de datosEn tiempo de compilación:● Insertar NOPs en el código● Reordenar el código
En tiempo de ejecución● Adelantar los datos (forwarding)● Frenar el pipeline (stall)
Dana K. Urribarri AC 2016 27
Read after Write● Ejemplo 1:
– i : R7 ← R12 + R15
– i+1 : R8 ← R7 – R12
– i+2 : R15 ← R8 + R7
Conflictos de datos
Dana K. Urribarri AC 2016 28
Read after WriteConflictos de datos
i+1 : R8 ← R7 – R12
i : R7 ← R12 + R15
i+2 : R15 ← R8 + R7
Se necesita R7
Se necesitan R7 y R8
Se escribe R7
Se escribe R8
Dana K. Urribarri AC 2016 29
Read after WriteConflictos de datos
i+3 : R8 ← R7 – R12
i : R7 ← R12 + R15
i+6 : R15 ← R8 + R7
i+1: NOP
i+2: NOP
i+4: NOP
i+5: NOP
R7
R8
WB escribe en la primera mitad del ciclo.ID lee en la segunda mita.
Dana K. Urribarri AC 2016 30
Read after WriteConflictos de datos
i+1 : R8 ← R7 – R12
i : R7 ← R12 + R15
i+2 : R15 ← R8 + R7
STALL
STALL
R7
R8
WB escribe en la primera mitad del ciclo.ID lee en la segunda mita.Los Stall se detectan en el decode.
Dana K. Urribarri AC 2016 31
Read after WriteConflictos de datos
i+1 : R8 ← R7 – R12
i : R7 ← R12 + R15
i+2 : R15 ← R8 + R7
Se necesitan R7 y R8
Se escribe R7
Se escribe R8
Acá ya se sabe R7
Acá ya se sabe R8Se necesita R7
Dana K. Urribarri AC 2016 32
Read after WriteConflictos de datos
i+1 : R8 ← R7 – R12
i : R7 ← R12 + R15
i+2 : R15 ← R8 + R7
Se escribe R7
Forwarding R8
Forwarding R7
Se escribe R8
Dana K. Urribarri AC 2016 33
Read after Write● Ejemplo 2:
– i: R6← Mem[R2]
– i+1: R7← R6 + R4
Conflictos de datos
Dana K. Urribarri AC 2016 34
Read after Write
i+1 : R7 ← R6 – R4
i : R6 ← Mem[R2]
R6 recién estádisponible acá
Conflictos de datos
STALL
Hasta después de MEM no se conoce R6.No hay otra opción que retardar 1 ciclo la instrucción.Hay forwarding pero 1 ciclo más tarde
Dana K. Urribarri AC 2016 35
Read after Write● Ejemplo 3:
– i: R10 ← R4 + R5
– i+1: R10← R10 + R4
– i+2: R8 ← R10 + R7
Conflictos de datos
Dana K. Urribarri AC 2016 36
Read after Write
i+1: R10← R10 + R4
i: R10 ← R4 + R5
Conflictos de datos
La lógica de forwarding debe permitir que el forwarding de R10 sea de i a i+1 y de i+1 a i+2.
i+2: R8 ← R10 + R7
Dana K. Urribarri AC 2016 37
Read after Write● Ejemplo 4:
– i: R5 ← Mem[R6]
– i+1: Mem[R8]← R5
Conflictos de datos
Dana K. Urribarri AC 2016 38
Read after Write
i+1: Mem[R8]← R5
i: R5 ← Mem[R6]
Conflictos de datos
La lógica de forwarding debe reconocer que el valor a escribir en memoria es que se acaba de leer en la instrucción anterior y no el valor del registro R5.
Dana K. Urribarri AC 2016 39
Unidades de Stall y Forwarding
Dana K. Urribarri AC 2016 40
Unidad de conflictos
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
SignExtend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE
1
0
PCF0
1PC' InstrD
25:21
20:16
15:0
5:0
SrcBE
25:21
15:11
RsE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchM
WriteRegM4:0
ResultW
PCPlus4F
31:26
RegDstD
BranchD
MemWriteD
MemtoRegD
ALUControlD2:0
ALUSrcD
RegWriteD
Op
Funct
ControlUnit
PCSrcM
CLK CLK CLK
CLK CLK
WriteRegW4:0
ALUControlE2:0
ALU
RegWriteE RegWriteM RegWriteW
MemtoRegE MemtoRegM MemtoRegW
MemWriteE MemWriteM
RegDstE
ALUSrcE
WriteRegE4:0
000110
000110
SignImmD
Sta
llF
Sta
llD
For
war
dAE
For
war
dBE
20:16RtE
RsD
RdD
RtD
Reg
Writ
eM
Reg
Writ
eW
Mem
toR
egE
Hazard Unit
Flu
shE
PCPlus4E
BranchE BranchM
ZeroM
EN
EN
CLR
Dana K. Urribarri AC 2016 41
Microarquitectura en pipeline1) Instruction fetch (IF). Se trae de memoria la instrucción en
la posición indicada por el PC. Se asume que la instrucción no es un branch y se incrementa el PC.
2) Instruction decode (ID). Se decodifica la instrucción y se reconoce su tipo. Se buscan los operandos.
3) Execution (EX). Se ejecuta la instrucción. Difiere si es una operación aritmética, un acceso a memoria o un branch.
4) Memory access (Mem). Se accede efectivamente a la memoria en caso de que la instrucción sea un acceso a memoria.
5) Writeback (WB). Si la instrucción no es un branch o un store, el resultado de la operación (o del load) se almacena en el registro resultado.
Dana K. Urribarri AC 2016 42
Datapath & control del pipeline
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
Sign Extend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE0
1
PCF0
1PC' InstrD
25:21
20:16
15:0
5:0
SrcBE
20:16
15:11
RtE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchM
WriteRegM4:0
ResultW
PCPlus4EPCPlus4F
31:26
RegDstD
BranchD
MemWriteD
MemtoRegD
ALUControlD
ALUSrcD
RegWriteD
Op
Funct
ControlUnit
ZeroM
PCSrcM
CLK CLK CLK
CLK CLK
WriteRegW4:0
ALUControlE2:0
ALU
RegWriteE RegWriteM RegWriteW
MemtoRegE MemtoRegM MemtoRegW
MemWriteE MemWriteM
BranchE BranchM
RegDstE
ALUSrcE
WriteRegE4:0
IF/IDFD
ID/EXDE
EX/MEMEM
MEM/WBMW
Dana K. Urribarri AC 2016 43
Conflictos de control● El PC se incrementa en el Fetch.● El pipeline trabaja bien cuando no hay
transferencia de control.● Instrucciones branch, jump, call y return
interrumpen el flujo secuencial del programa y crean conflictos de control.
● Tanto la dirección de salto como la condición (branch) se calculan en Execute.
● Por lo tanto, recién se decide y se modifica el PC en Memory.
Dana K. Urribarri AC 2016 44
Branch● La condición del branch y el PC destino no se
saben hasta la 4ta etapa del pipeline.● Hasta ese momento se hizo el fetch de las tres
instrucciones siguientes al branch.● Pero si hay que saltar esas instrucciones deberán
descartarse.
Conflictos de control
Dana K. Urribarri AC 2016 45
Branch
Time (cycles)
beq $t1, $t2, 40 RF $t2
$t1RF- DM
RF $s1
$s0RF& DM
RF $s0
$s4RF| DM
RF $s5
$s0RF- DM
and $t0, $s0, $s1
or $t1, $s4, $s0
sub $t2, $s0, $s5
1 2 3 4 5 6 7 8
and
IM
IM
IM
IMlw
or
sub
20
24
28
2C
30
...
...
9
Flushthese
instructions
64 slt $t3, $s2, $s3 RF $s3
$s2RF
$t3slt DMIM
slt
Conflictos de control
Dana K. Urribarri AC 2016 46
Penalización del branch● Es la cantidad de instrucciones que se descartan
cuando se toma el branch.● Puede reducirse determinando el branch antes
(cuando sea posible).● Branch on equal:
– Un comparador de igualdad es mucho más rápido que restar y detectar resultado cero.
– Si es lo suficientemente rápido se podría mover al decode y determinar el PC en el decode.
Conflictos de control
Dana K. Urribarri AC 2016 47
Jump● El jump (call y return) es un salto incondicional.● En el pipeline básico el PC destino no se saben
hasta la 4ta etapa del pipeline.● Tiene la misma penalización que el branch.● Puede reducirse adelantando el cálculo de la
dirección destino (al decode).
Conflictos de control
Dana K. Urribarri AC 2016 48
EqualD
SignImmE
CLK
A RD
InstructionMemory
+
4
A1
A3
WD3
RD2
RD1WE3
A2
CLK
SignExtend
RegisterFile
0
1
0
1
A RD
DataMemory
WD
WE
1
0
PCF0
1PC' InstrD
25:21
20:16
15:0
5:0
SrcBE
25:21
15:11
RsE
RdE
<<2
+
ALUOutM
ALUOutW
ReadDataW
WriteDataE WriteDataM
SrcAE
PCPlus4D
PCBranchD
WriteRegM4:0
ResultW
PCPlus4F
31:26
RegDstD
BranchD
MemWriteD
MemtoRegD
ALUControlD2:0
ALUSrcD
RegWriteD
Op
Funct
ControlUnit
PCSrcD
CLK CLK CLK
CLK CLK
WriteRegW4:0
ALUControlE2:0
AL
U
RegWriteE RegWriteM RegWriteW
MemtoRegE MemtoRegM MemtoRegW
MemWriteE MemWriteM
RegDstE
ALUSrcE
WriteRegE4:0
000110
000110
=
SignImmD
Sta
llF
Sta
llD
For
war
dAE
For
war
dBE
20:16RtE
RsD
RdE
RtD
Reg
Writ
eM
Reg
Writ
eW
Mem
toR
egE
Hazard Unit
Flu
shE
EN
EN
CLR
CLR
Determinación temprana del saltoConflictos de control
Dana K. Urribarri AC 2016 49
Gestión de conflictos de control● A nivel compilador
– Insertar NOPs
– Reordenar el código(branch retardado)
● A nivel hardware– Frenar el pipeline
– Predicción del branch● Estática● Dinámica
No siempre es posible encontrarcódigo útil para retardar el branch.
Disminuye el rendimiento del procesador
Disminuye el rendimiento del procesador
Dana K. Urribarri AC 2016 50
Predicción del branch● En un procesador en pipeline el CPI ideal es 1.● La penalización del branch es un factor
importante en el incremento del CPI.● Predictor de branch:
– Predecir si el branch será tomado o no.
● La implementación sin predicción, equivale a predecir que será no tomado.
Dana K. Urribarri AC 2016 51
Predicción estática del branch
● No depende de la historia del programa.● Al final de los bucles (for, while) hay un salto para
volver al principio y eso se repite varias veces.● Los saltos hacia atrás son generalmente
tomados.
● La predicción más simple controla la dirección del salto y predice tomado para los saltos hacia atrás.
Dana K. Urribarri AC 2016 52
Predicción dinámica del branch
● La predicción de los saltos hacia adelante necesitan más información del programa.
● Los predictores dinámicos usan la historia de ejecución del programa para predecir si el branch será tomado o no.
● Se mantiene una tabla de las últimas cien (o mil) instrucciones branch ejecutadas.
● Branch target buffer: incluye destino del branch e historia pasada.
Dana K. Urribarri AC 2016 53
Predicción dinámica del branch
● La predicción debe hacerse en la etapa IF para determinar qué instrucción ejecutar en el próximo ciclo.
● Cuando predice que debe saltar, la próxima instrucción es la indicada en el branch target buffer.
● Si en el branch target buffer se tiene información de branch y jump, se evita la penalización de los jumps.
Dana K. Urribarri AC 2016 54
Predictor dinámico de 1 bit● Recuerda qué ocurrió la última vez y predice lo
mismo.– Mientras se repite el bucle,
recuerda que el beq no salta y predice correctamente.
– Luego del último ciclo, el branch salta, pero predice no tomado.
– Si el bucle vuelve a ejecutarse, el predictor recuerda no tomado y predice erróneamente en la primera iteración.
R0 ← 0R1 ← 10For:
Beq R0, R1, done…Add R0, R0, 1
Done:
Dana K. Urribarri AC 2016 55
Predictor dinámico de 2 bits● Para realizar la predicción distingue entre 4
estados.Varían en cuantas veces debe ocurrir:● no-tomado para que pase de
strongly-taken a strongly-no-taken.
● tomado para que pase de strongly-no-taken a strongly-taken.
Dana K. Urribarri AC 2016 56
Predictor dinámico de 2 bits● Para realizar la predicción distingue entre 4
estados.
R0 ← 0R1 ← 10For:
Beq R0, R1, done…Add R0, R0, 1
Done:
La primera vez, predice no tomado, y efectivamente no debía saltar.Sigue prediciendo no tomado, incluso luego de la última iteración.Pero en la última iteración debía saltar.
Dana K. Urribarri AC 2016 57
Análisis de rendimiento
T 1=Tiempo de procesamiento sin pipelineT k=Tiempo de procesamiento en pipeline con k etapas
SpeedupPipeline=T 1
T k
Av 1=Tiempo promedio de procesamiento sin pipelineAv k=Tiempo promedio de procesamiento en k etapas
SpeedupPipeline=Av1
Av k
Dana K. Urribarri AC 2016 58
Análisis de rendimiento● Ciclos por instrucción (pipeline de k etapas)
– 1 instrucción → k ciclos
– n instrucciones → k + n – 1 ciclos
– En promedio
– Idealmente
– CPI = CPIideal + Ciclos Stall por instrucción = 1 + Ciclos Stall por instrucción
CPIideal=limn→∞
nk +n−1
=1
1 instrucción demanda: n
k +n−1
Profundidad del pipeline
Dana K. Urribarri AC 2016 59
Análisis de rendimiento● Los stalls causan que baje el rendimiento del
pipeline.
● Período del relojúnico ciclo = k × Período del relojpipeline
● CPIúnico ciclo = 1
Av 1=CPIúnico ciclo×Período del relojúnico ciclo
Av k=CPIpipeline×Período del relojpipeline
SpeedupPipeline=Av 1
Av k
Dana K. Urribarri AC 2016 60
Análisis de rendimiento
● Si no hay Stalls, el Speedup del pipeline es igual a la profundidad k del pipeline.
Av 1=1×k×Período del relojpipeline
Av k=(1+Ciclos Stall por instrucción)×Período del relojpipeline
SpeedupPipeline=Av 1
Av k
=k
1+Ciclos Stall por instrucción
Dana K. Urribarri AC 2016 61
Análisis de rendimientoPipeline de 5 etapas.● Branch sin predicción. Branch y jump actualizan el
PC en Memory. → Se descartan 3 instrucciones.● 25% load● 11% branch● 2% jump● 40% de los load están seguidos de una instrucción
que usa el dato → requiere un stall● 60% de los branch se toman → requiere descartar
tres instrucciones.
Dana K. Urribarri AC 2016 62
Análisis de rendimiento● Ciclos Stall por instrucción
+ 25% load * 40% * 1
+ 11% branch * 60% * 3
+ 2% jump * 3
≈ 0.36
SpeedupPipeline=5
1+0.36≈3.68
Dana K. Urribarri AC 2016 63
Análisis de rendimientoPipeline de 5 etapas.● Predicción de branch. Branch y jump se resuelven
en ID → Se descarta una instrucción.● 25% load● 11% branch● 2% jump● 40% de los load están seguidos de una instrucción
que usa el dato → requiere un stall● 25% de los branch se predicen mal → requiere
descartar una instrucción.
Dana K. Urribarri AC 2016 64
Análisis de rendimiento● Ciclos Stall por instrucción
+ 25% load * 40% * 1
+ 11% branch * 25% * 1
+ 2% jump * 1
≈ 0.15
SpeedupPipeline=5
1+0.15≈4.35
Dana K. Urribarri AC 2016 65
Instruction-level parallelism● El objetivo es aprovechar al máximo el
paralelismo a nivel de instrucciones para ejecutar múltiples instrucciones por ciclo.
CPI = 1.0CPI > 1 CPI < 1
Pipeline
Instruction-levelparallelism
Multi-cycledatapaths
SuperscalarVLIWEPIC
Dana K. Urribarri AC 2016 66
Bibliografía● Capítulo 2. Multiprocessor Architecture. From simple
pipelines to chip multiprocessor. Jean-Loup Baer. Cambridge University Press. 2010.
● Capítulo 7. David Money Harris & Sarah L. Harris. Digital Design and Computer Architecture. Elsevier. 2013, 2da Ed.
Suplementaria● Apéndice C. John L. Hennessy & David A. Patterson.
Computer Architecture. A Quantitative Approach. Elsevier Inc. 2012, 5ta Ed.
● Capítulo 4. David A. Patterson & John L. Hennessy. Computer Organization and Design. The Hardware/Software Interface. Elsevier Inc. 2014, 5ta Ed.