¿Cómo es posible que la cantidad de ciclos de reloj necesarios para completar una instrucción en un procesador segmentado sea menor que la latencia de la segmentación?

No soy nuevo en la arquitectura de computadoras, pero solo tengo experiencia académica con la implementación de microarquitectura.

Escuché y leí esto muchas veces, pero nunca me molesté en entender la declaración: algunas instrucciones se completan en 1 o 2 ciclos de reloj, mientras que las instrucciones más complejas dicen que el número entero o el punto flotante se completan en 2, 4, 6 ciclos de reloj, etc. o cargar/almacenar en 80-100 ciclos de reloj debido a la memoria lenta.

Ahora estoy seguro de que la mayoría de los procesadores, ya sean integrados o de escritorio, tienen pocas etapas de canalización, digamos desde 5 etapas hasta 30 etapas. Por lo tanto, la latencia de cada instrucción debe ser igual a la profundidad de la canalización o al número de etapas de la canalización. Además, el rendimiento de un solo procesador escalar de canalización puede ser de un máximo de 1 IPC (Instrucciones por ciclo). Pero, ¿cómo pueden terminar algunas instrucciones en 1, 2 o 4 ciclos de reloj para un procesador con tubería de 10 o 12 etapas? ¿Alguien puede explicarme eso?

PD: Lo único que puedo entender es que tal vez algunas etapas estén marcadas como una etapa de ciclo múltiple, como generalmente se hace durante el STA y el cierre de tiempo. ¿Y que están tratando de decir que la ejecución de la instrucción toma 1cc, 2cc, 4cc, etc. en esa etapa de ciclo múltiple en particular?

Una instrucción específica 'usa' solo la etapa de canalización que necesita, las demás se 'omiten'. ¡No tendría sentido hacer (= esperar) las etapas de obtención de operandos de la memoria y ALU en una instrucción de movimiento de registro a registro!
¿Dónde leyó su declaración citada? Me parece algo que podría decirse sobre una generación anterior de procesadores (por ejemplo, la era 6800/8086) antes de que las arquitecturas de tubería se volvieran comunes. Para una arquitectura canalizada, lo más probable es que diga algo como "el procesador tiene un rendimiento de 1 (o 2) ciclos por instrucción".
@WoutervanOoijen: Sí, absolutamente correcto. Por lo tanto, algunas instrucciones pueden tener una latencia mayor y otras menor.

Respuestas (3)

En general, el tiempo de ejecución de la instrucción no se mide desde que ingresa a la canalización hasta que sale, sino desde el momento en que pasa por algún punto arbitrario de la canalización hasta el momento en que la siguiente instrucción pasa por ese punto. Si ninguna instrucción tarda más de, por ejemplo, 20 ciclos en recorrer la tubería, medir el tiempo que tarda una secuencia de instrucciones en pasar por algún estado arbitrario arrojará un resultado que está dentro de los 20 ciclos del tiempo real requerido para ejecutar toda la secuencia desde Empezar a acabar. Dado que los programadores generalmente están mucho menos interesados ​​​​en el tiempo para ejecutar una sola instrucción que en el tiempo requerido para ejecutar secuencias que contienen muchas instrucciones (a menudo miles, si no más),

"La medición del tiempo que tarda una secuencia de instrucciones en pasar por un estado arbitrario arrojará un resultado dentro de los 20 ciclos del tiempo real requerido para ejecutar toda la secuencia de principio a fin". ¿No estaría el tiempo para ejecutar una secuencia arbitraria dentro de los ciclos de "20 más el número de insns en la secuencia", asumiendo que un insn ingresa a la tubería por ciclo?
Si cada instrucción pasa por la misma secuencia de 20 estados, entonces el tiempo medido sería exactamente 20 ciclos más corto que el tiempo real. Si el tiempo medido es 1000, el tiempo real sería 1020. La razón por la que dije "dentro" es para permitir la posibilidad de que una canalización tenga 8 etapas, pero se detenga por un total de 12 ciclos mientras las procesa. Ninguna instrucción tardaría más de 20 ciclos en pasar por la canalización, pero el tiempo total podría oscilar entre (medida+8) y (medida+20). En todos los casos, sin embargo, sería "dentro de 20".

La longitud de la tubería es solo el retraso entre la entrada y la salida.

Ciclos para completar es la cantidad de tiempo que necesita por operación.

Esto no es lo mismo, uno es "retraso" y el otro es "velocidad". Por lo tanto, es perfectamente posible tener tuberías y múltiples ciclos por instrucción en cualquier proporción.

Suponga que tiene una canalización de 5 etapas y necesita 3 ciclos por instrucción. Esto significa que los siguientes dos ciclos después de aplicar una entrada, la unidad no está lista para aceptar una nueva entrada. Además de eso, hay un retraso de 5 ciclos debido a la tubería. Por lo tanto, se necesitan 8 ciclos desde que se aplica la entrada hasta que el resultado está disponible. Pero con respecto al rendimiento, solo se necesitan 3 ciclos por operación. Es decir, aunque el primer resultado no se complete por completo, en el tercer ciclo se puede aceptar una nueva entrada y se inicia el cálculo (y los resultados se obtienen 8 ciclos después).

Con una tubería, está haciendo cosas en paralelo (a costa de la demora), que de otro modo tendría que hacer en serie (más ciclos por operación).

Entiendo la mayoría de tus puntos. Pero no puedo entender su comentario: "necesita 3 ciclos por instrucción". ¿Quiere decir IPC promedio? Y también el comentario: "3 ciclos por operación": ¿quiere decir que la ejecución de la operación real en una etapa determinada requiere 3 ciclos?
Por 3 ciclos/instrucción me refiero a un IPC de 1/3. O en el tiempo correspondiente a 3000 ciclos se pueden completar 1000 instrucciones. Así que creo que la respuesta a tu pregunta es sí.

Me parece imposible tener una instrucción que pueda pasar por todas las etapas de la canalización (Obtener -> Decodificar -> ...) en uno o dos ciclos de reloj. El "tiempo de ejecución" como lo citó es, probablemente, algún tipo de jerga.

La mejor suposición que puedo hacer sin poder ver todo el contexto de la declaración que lo desconcierta, es que estos números representan el "bloqueo" de la tubería cuando se ejecuta la instrucción de algún tipo. La otra forma de decirlo es que este número representa el rendimiento teórico de la canalización si solo se ejecutaran las instrucciones de este tipo.

Por ejemplo:

  • Si las únicas instrucciones que se suministran a la canalización pudieran ser Mover entre registros, el rendimiento de la canalización sería igual a 1: en cada ciclo de reloj se completa una instrucción.
  • Si la única instrucción que se suministra a la canalización pudiera ser Cargar desde la memoria, el rendimiento de la canalización sería igual a 1 100 (suponiendo que esta instrucción detenga la canalización durante 100 ciclos de reloj).

En las CPU modernas de canalización múltiple, no sirve de mucho el "tiempo de ejecución de instrucciones" sin procesar solo. El empleo de almacenamiento en caché de varios niveles, ejecución fuera de orden, bifurcación predictiva y muchos más, complica el análisis y mitiga la penalización de detener una sola canalización. En ocasiones esta penalización puede reducirse a cero.

Sí, la fuente de este estancamiento de la canalización es el hecho de que algunas instrucciones pueden tener etapas de "ciclo múltiple". Sin embargo, el uso de "ciclo múltiple" en este contexto no siempre es el mismo que el uso de "ciclo múltiple" en el contexto de las herramientas STA. La etapa multiciclo de canalización puede ser una etapa combinatoria que requiere pocos ciclos de reloj (en cuyo caso también debe definirse como multiciclo para herramientas STA), o puede ser una etapa secuencial que requiere más de un ciclo de reloj para funcionar. completo (en cuyo caso todavía necesita cumplir con el tiempo como una sola etapa del ciclo).

Considere una canalización de 10 etapas con una instrucción de adición de punto flotante de 32 bits FPADD Dest, Src1, Src2. La instrucción FPADD pasa por varias etapas (Fetch, Decode, ..) y toma 1 cc en cada una de estas etapas antes de llegar a la etapa Exec. La adición real ocurre en la etapa Exec, donde se necesitan 4 ciclos de reloj para realizar esta operación. Esto podría suceder de 2 maneras: 1: la unidad Adder FP está canalizada con 4 registros de canalización 2: si es una ruta puramente combinatoria, entonces se marca como una ruta de ciclo múltiple de 4 ciclos. En general, FP ADD aún requiere al menos 10+4=14 ciclos (LATENCIA) para salir de la canalización.
Si ejecutamos 101 instrucciones FPADD independientes, tomaría 14+100*1= 114 ciclos de reloj. Esto da IPC (tasa de rendimiento o finalización) = 101/114 = 0,88. Entonces, si alguien dice que "Cada operación FP ADD toma 4 cc" solo tiene sentido para la operación FP real que ocurre en la etapa Exec. Ni la latencia ni el rendimiento de las instrucciones tienen nada que ver con eso. ¿no es así?
@nurabha, si cada etapa ejecutiva detiene la canalización durante 3 ciclos de reloj adicionales, ¿cómo es que el rendimiento será 1? Creo que la ejecución de 101 de tales instrucciones tomará ∼ 14 + 100 ∗ 4 = 414 ciclos de reloj
Por favor, corríjame si estoy equivocado. Creo que las paradas de 3 ciclos serán causadas por la etapa exec solo cuando el sumador FP no es una unidad canalizada, es decir, es una unidad combinacional con un retraso de 4 cc (multiciclo). Sin embargo, si el sumador FP está canalizado con 4 registros de canalización, ¿entonces no se producirían bloqueos en la etapa exec, ya que 4 pares de operandos pueden estar en vuelo juntos en la etapa exec? Entonces, ¿su respuesta es correcta para el primer caso y mi respuesta es correcta para el segundo caso?
@Vasily: Con tus 414 ciclos de reloj. IPC ~ 4.15. Solo que ahora tiene sentido la declaración "Cada operación FP Add toma 4 cc".
@nurabha, lo que describe no es una sola etapa de "ciclo múltiple" de la tubería, sino una tubería más larga donde la etapa de ejecución se divide en varias etapas de tubería. Hay una diferencia crucial: la etapa de "ciclo múltiple" no puede aceptar nuevos datos antes de que se complete la ejecución del comando anterior, lo que agrega paradas. Una sola etapa que se divide en múltiples etapas de canalización no agrega paradas. Sin embargo, solo las operaciones comunes obtienen múltiples etapas de canalización. Es un desperdicio agregar 5 etapas a la canalización porque un solo comando lo necesita.
¿Cómo es posible que la cantidad de ciclos de reloj necesarios para completar una instrucción en un procesador segmentado sea menor que la latencia de la segmentación?
RespuestasAquíPolítica de privacidad1y, 4v