¿Por qué las ALU aún son seriales?

Si la adición es inaccesible mientras la multiplicación aún se está ejecutando, es porque la multiplicación también requiere algunas operaciones de suma (junto con algunos cambios).

De lo contrario, la ALU necesita tener más de un sumador (lo que no es en absoluto realista).

Por cierto: si la ALU no puede realizar más de una operación aritmética al mismo tiempo, no lo llamaría "serial" (porque recuerda demasiado a sumador serial ; que realiza la operación de agregar bit por bit ).
Si la CPU no puede hacer más de una instrucción al mismo tiempo (en un ciclo) simplemente se llama "no superscalar ".

Existe el problema Silicio oscuro : cada cálculo genera algo de calor. Hacer que todas y cada una de las partes de la ALU hagan cálculos al mismo tiempo puede generar suficiente calor para derretir el chip. Darle descanso a las diferentes partes de la ALU de vez en cuando ayuda a diseminar el calor y mantener la temperatura pico lo suficientemente baja como para ahorrar la operación. (Esto se aplica principalmente a CPU muy rápidas y altamente densas, como la CPU de su PC. Los microcontroladores no suelen verse afectados por esto).

Para las arquitecturas no tan rápidas, esto no suele ser una gran cosa, y las arquitecturas especializadas que intentan mantener ocupados todos los aspectos de la ALU existen. Sin entrar en mucho detalle, la arquitectura DSP C6x de TI, por ejemplo, permite algunas locuras. Tiene ocho tuberías ALU especializadas que permiten aproximadamente hasta dos docenas de instrucciones activas al mismo tiempo. Si bien esto suena bien desde el punto de vista del rendimiento, tiene un serio inconveniente: escribir código que mantiene a todos los canales ocupados es muy difícil. Depurar el código es aún más difícil. Usted obtiene un gran rendimiento de ALU por vatio de dicha arquitectura, pero los costos de desarrollo explotan.

En primer lugar, debes tener en cuenta que básicamente estás equivocado: aunque ciertamente hay límites, una CPU moderna puede ejecutar varias instrucciones simultáneamente.

Usemos la nueva arquitectura Zen de AMD como ejemplo. Su encarnación actual es compatible con el despacho (es decir, la ejecución inicial de) hasta 12 microoperaciones por ciclo de reloj (6 enteros, 6 puntos flotantes, aunque hay algún desacuerdo al respecto, algunas fuentes dicen que solo 4 puntos flotantes).

Aunque eso claramente podría incrementarse, hacerlo no sería trivial. Solo por un punto obvio, no es solo una cuestión de poder ejecutar más microoperaciones por reloj.

Para operaciones de enteros, debe admitir 128 bits de entradas para muchas de las operaciones simples (sumar, restar y xor, no), pero tiene algunas operaciones que necesitan aún más (por ejemplo, la división de enteros requiere una tamaño normal y una entrada de tamaño doble, por lo que toma 192 bits de operandos de entrada).

Peor aún, para tener una buena oportunidad de ejecutar más operaciones por reloj, necesitas un grupo más grande de operaciones descodificadas disponibles para despachar. Es probable que también necesites tener más registros físicos (el diseño actual de AMD usa 168) para admitir más renombrados de registros y darte la oportunidad de encontrar más operaciones que realmente se ejecuten en un ciclo de reloj determinado.

Por lo tanto, su diseño rápidamente globos. En este momento, AMD aparentemente necesita alrededor de dos docenas de MUXes de 168 entradas para recuperar las entradas de los registros en las unidades de ejecución (de anchos que varían desde 64 bits hasta 256 bits), y otra docena (o así) de demuxers para almacenar los resultados.

Si desea duplicar la tasa de ejecución posible, obviamente deberá aumentar el número de MUXes de dos a docenas. Sin embargo, para darte la oportunidad de ejecutar más instrucciones, deberías aumentar tu banco de registro físico de 168 a alrededor de 336 registros, por lo que no solo necesitas el doble de MUX, sino que cada uno se vuelve sustancialmente más grande. también. Del mismo modo, para almacenar sus resultados, tendría que aumentarlos de una a dos docenas de demuxes, y, nuevamente, cada uno debería ser más grande para admitir más registros físicos.

Entonces tienes el hecho de que actualmente solo puedes decodificar 4 instrucciones por reloj. Si desea ejecutar 24 operaciones por reloj, es probable que tenga que decodificar alrededor de 8 instrucciones por reloj: la capacidad de ejecutar 24 microoperaciones por reloj no ganará mucho si no puede decodificar tantas. .

Desafortunadamente, las instrucciones x86 no son fáciles de decodificar, por lo que duplicar el número de decodificadores es una propuesta bastante costosa también.

Resultado final: un diseño de CPU decente depende de equilibrar los recursos en todo el diseño. Si desea poder lograr cualquier cosa al poder enviar más operaciones por reloj, tendrá que realizar cambios en casi todo el diseño.

Todo eso, por supuesto, podría hacerse, pero comienza a agotar una gran cantidad de silicio muy rápidamente. En la actualidad, parece que obtienes más al usar ese silicio de otras maneras (más núcleos, caché más grande, más controladores de memoria, más líneas PCIe, etc.)

En al menos un caso es muy común: la funcionalidad DSP generalmente tiene una instrucción MAC (acumulación múltiple) porque es una operación que se realiza con mucha frecuencia en el procesamiento de señales digitales.

No creo que el uso de diferentes partes de la ALU de forma independiente sea "gratuito", sin embargo, podría ser más económico en términos de área de silicio tener un segundo sumador en lugar de tratar de usar uno para dos propósitos. para ser puntos de entrada de bus adicionales o lo que sea, y porque las puertas requeridas para un sumador solo se escalan con el número de bits n. Los multiplicadores paralelos se escalan como n ^ 2, por lo que serán costosos de implementar, especialmente para n grandes.

La Multiflow Corporation vendió máquinas con instrucciones de 128 bits y de 256 bits. Se realizaron muchas actividades en paralelo. La clave fue el compilador.

Intel compró Multiflow hace décadas.