Pipelining

1. Pipelining Peligros (hazards)

2. Peligros (hazards) • Eventos que evitan que la siguiente instrucción se ejecute en el siguiente ciclo de reloj. • Estructurales. • Motivo: conflictos de recursos. • Solución: duplicación de recursos. • Datos. • Motivo: dependencias entre instrucciones. • Soluciones: forwarding (bypassing) y reordenamiento de instrucciones. Arquitectura de Computadoras

3. Peligros (hazards) • Control (brincos). • Motivo: en un brinco no se conoce la siguiente instrucción hasta que la instrucción de brinco sale del pipeline. • Soluciones: detener (stall) el pipeline, especular (adivinar) la siguiente instrucción y decisión retrasada (delayed decision). Arquitectura de Computadoras

4. Peligrosestructurales • Motivo: conflicto de recursos. • Solución: duplicar recursos. • Ejemplo: IF e ID necesitan acceso a la memoria. • Solución: separar la memoria de instrucciones y la memoria de datos. • Ejemplo: IF y MEM necesitan acceso al PC. • Solución: tener 2 copias del PC. Un PC apunta a la siguiente instrucción y otro a la instrucción que está siendo ejecutada. Arquitectura de Computadoras

5. Peligros de datos • Consecuencia: una instrucción, B, en el pipeline debe esperar a que otra instrucción, A, termine. • Conocido como peligro RAW (read-after-write). • Motivo: B depende de A. • Ejemplo: A: add $s0, $t0, $t1 ; s0 = t0 + t1 B: sub $t2, $s0, $t3 ; t2 = s0 - t3 • Hay una dependencia de datos, también conocida como dependencia de datos verdadera. Arquitectura de Computadoras

6. Peligros de datos • B necesita el valor de s0 en la etapa EX. • A no escribe s0 hasta la etapa WB. Arquitectura de Computadoras

7. Peligros de datos • Soluciones: • Detener (stall) el pipeline. B no comienza hasta que A termine. • Forwarding (bypassing). Conectar por hardware las etapas del pipeline. Arquitectura de Computadoras

8. Peligros de datos • Forwarding no soluciona todos los peligros RAW. • Ejemplo: A: lw $s0, 20($t1) ; s0 = Mem[t1 + 20] B: sub $t2, $s0, $t3 ; t2 = s0 - t3 • s0 se calcula en la etapa MEM de A. • Ya es tarde para hacer un forwarding a la etapa EX de B. • El pipeline se detiene (stall) un ciclo. Arquitectura de Computadoras

9. Peligros de datos • Forwarding no resuelve los peligros RAW cuando una instrucción tipo-R sigue a una instrucción de acceso a memoria (lw/sw). Arquitectura de Computadoras

10. Peligros de datos • Reordenar instrucciones. • El sentido del programa no debe cambiar. • Ejemplo: A: lw $s0, 20($t1) ; s0 = Mem[t1 + 20] B: sub $t2, $s0, $t3 ; t2 = s0 - t3 • Solución: A: lw $s0, 20($t1) ; s0 = Mem[t1 + 20] C: lw $t4, 8($a0) ; t4 = Mem[a0 + 8] B: sub $t2, $s0, $t3 ; t2 = s0 - t3 Arquitectura de Computadoras

11. Ejemplo • Encontrar las dependencias en el siguiente código y reordenar las instrucciones para evitarlas. • Código en C/Java A = B + E C = B + F Arquitectura de Computadoras

12. Ejemplo • Código MIPS • Asumiendo que B está apuntada por t0, E por t0+4, F por t0+8, A por t0+12 y C por t0+16. 1. lw $t1, 0($t0) ; t1 = Mem[t0] 2. lw $t2, 4($t0) ; t2 = Mem[t0+4] 3. add $t3, $t1, $t2 ; t3 = t1 + t2 4. sw $t3, 12($t0) ; Mem[t0+12] = t3 5. lw $t4, 8($t0) ; t4 = Mem[t0+8] 6. add $t5, $t1, $t4 ; t5 = t1 + t4 7. sw $t5, 16($t0) ; Mem[t0+16] = t5 Arquitectura de Computadoras

13. Ejemplo • Dependencias de datos: • 1 y 3. • 2 y 3. • 3 y 4. • 5 y 6 • 6 y 7 • Forwarding (bypassing) elimina todas las dependencias excepto b) y d). Arquitectura de Computadoras

14. Ejemplo • Las dependencias b) y d) se resuelven moviendo la instrucción 5 hacia arriba: 1. lw $t1, 0($t0) ; t1 = Mem[t0 2. lw $t2, 4($t0) ; t2 = Mem[t0+4] 5. lw $t4, 8($t0) ; t4 = Mem[t0+8] 3. add $t3, $t1, $t2 ; t3 = t1 + t2 4. sw $t3, 12($t0) ; Mem[t0+12] = t3 6. add $t5, $t1, $t4 ; t5 = t1 + t4 7. sw $t5, 16($t0) ; Mem[t0+16] = t5 Arquitectura de Computadoras

15. Peligros de control • También llamados peligros de brincos. • No se sabe que instrucción sigue a un brinco. • Ejemplo: beq $t0, $t1, etiqueta instrucción_1 … etiqueta: instrucción_2 Arquitectura de Computadoras

16. 3 instrucciones comienzan antes de saber que debe brincar. Arquitectura de Computadoras

17. Peligros de control • Soluciones: • Detener (stall) el pipeline hasta que el brinco termine su etapa MEM. Muy lento • Reducir el retraso. Usar hardware extra para que el PC se conozca al final de la etapa ID. Arquitectura de Computadoras

18. Peligros de control • Ventajas de la solución 2: • El pipeline se detiene 1 ciclo Arquitectura de Computadoras

19. Peligros de control • Desventajas de la solución 2: • Hardware extra en la etapa ID: unidad de comparación, sumador para el PC y bypass al siguiente ciclo (incluyendo lógica extra para su manejo). • Se generan nuevos peligros de datos: si la instrucción anterior escribe uno de los operandos se tiene que detener el pipeline. Arquitectura de Computadoras

20. Costo de detener el pipeline • Según SPECint2000: • El 13% de las instrucciones son brincos. • El CPI de las instrucciones es 1. • Como los brincos tardan un ciclo extra, el CPI se incrementa a 1.13. • Si no se cuenta con hardware extra, el PC se conoce al final de la etapa MEM y el pipeline se detiene tres ciclos por cada brinco. • Conclusión: detener el pipeline no es práctico. Arquitectura de Computadoras

21. Peligros de control • Predecir que todos los brincos son no tomados. • Si se acierta, el pipeline continúa a toda velocidad. • Si no se acierta, es necesario deshacer lo que se haya hecho. • Problema: se necesita hardware extra para limpiar (flush) el pipeline. Arquitectura de Computadoras

22. Peligros de control • Brinco no tomado (acierto) Arquitectura de Computadoras

23. Peligros de control • Brinco tomado (no acierto) Arquitectura de Computadoras

24. Peligros de control • Especulación (adivinar) la siguiente instrucción. • Si se acierta, el pipeline continúa a toda velocidad. • Si no se acierta, es necesario deshacer lo que se haya hecho. Arquitectura de Computadoras

25. Peligros de control • Usar criterios estáticos. Por ejemplo, asumir que todos los brincos hacia arriba son parte de un ciclo y marcarlos siempre como tomados. • Criterios dinámicos. Llevar una historia reciente de cada brinco. Algunos algoritmos dinámicos aciertan hasta el 90% de veces. Arquitectura de Computadoras

26. Peligros de control • Decisión retrasada (delayed decision) • Usada en MIPS. • La siguiente instrucción a un brinco se ejecuta siempre. • El ensamblador coloca después de la instrucción de brinco alguna instrucción que no sea afectada por el brinco. • Hay 3 formas de escoger la instrucción. Arquitectura de Computadoras

27. Peligros de control Arquitectura de Computadoras

28. Peligros de control • La opción (a) es la preferida. • Las opciones (b) y (c) se usan si (a) no es posible. • La opción (b) es conveniente en brincos que son tomados con alta probabilidad, como en ciclos. • La instrucción que se usa en (b) y (c) debe ser una que no afecte el sentido del programa si el brinco va en sentido contrario. Arquitectura de Computadoras

29. Peligros de control • Ejemplo: add $a0, $a1, $a2 beq $at, $v0, Etiqueta lw $v1, 300($zero) • Como la suma no depende del brinco se reordena a: beq $at, $v0, Etiqueta add $a0, $a1, $a2 lw $v1, 300($zero) Arquitectura de Computadoras

30. Resumen Pipelining: • Explota el paralelismo entre instrucciones en un flujo secuencial. • Incrementa el número de instrucciones que se ejecutan simultáneamente. • Incrementa la tasa (rate) a la cual las instrucciones comienzan y son ejecutadas. • No reduce la latencia, el tiempo que de ejecución de una instrucción individual. Arquitectura de Computadoras

31. Resumen • Mejora el throughput, la cantidad de trabajo hecha por unidad de tiempo. • Existen peligros (hazards) estructurales, de datos y de control. • Parar (stall) el pipeline, predicción de brincos y forwarding ayudan a resolver los peligros. Arquitectura de Computadoras