Microarquitectura de CPU y rendimiento: más allá de los GHz

Informatec Digital » Recursos » Microarquitectura de CPU y rendimiento: más allá de los GHz

La microarquitectura de una CPU suele quedar en un segundo plano frente a cifras más llamativas como los GHz o los MB de caché, pero es justo ahí, en el diseño interno del procesador, donde se decide la mayor parte de su rendimiento real, su eficiencia y hasta qué tipo de software puede aprovecharlo mejor.

Cuando lees fichas técnicas que hablan de núcleos, hilos, caché L3 o AVX2, en realidad estás viendo consecuencias concretas de una microarquitectura determinada. Entender cómo se organizan esas piezas por dentro, qué hace diferente a un Zen 3 de un Zen 2 o a un Intel híbrido de un Ryzen clásico, es clave para elegir bien tu próxima CPU y saber por qué unas vuelan en juegos, otras en render y otras en tareas de servidor.

ISA, macroarquitectura y microarquitectura: poner orden en los conceptos

Antes de meterse en berenjenales de pipelines y predictores, conviene separar tres niveles que a menudo se mezclan: macroarquitectura del sistema, ISA y microarquitectura. Cada uno describe una capa distinta del ordenador.

Por un lado está la macroarquitectura o diseño global del sistema, que engloba todo lo que ves en la placa base: CPU, controladores de memoria, buses, memoria principal, chips de entrada/salida, controladoras de almacenamiento, posibles aceleradores externos y lógica de DMA. Es la foto de alto nivel de cómo se conectan los grandes bloques de hardware y cómo fluyen los datos entre ellos.

Encima de eso se sitúa la ISA (Instruction Set Architecture), que es el repertorio de instrucciones que entiende el procesador: tipos de datos que maneja, tamaño de palabra, cantidad y tipo de registros, modos de direccionamiento, formatos de instrucción, etc. Cuando programas en ensamblador usando mnemónicos como ADD, SUB, MUL o invocas extensiones como SSE, AVX o NEON, estás hablando directamente con la ISA.

Y finalmente tenemos la microcódigo o μISA, que define las microoperaciones internas con las que algunas arquitecturas complejas (como x86) implementan sus instrucciones CISC. Ese microcódigo puede actualizarse vía firmware para corregir bugs o añadir soporte a nuevas instrucciones.

Qué es exactamente la microarquitectura de una CPU

La microarquitectura CPU es, en esencia, el plano interno que decide cómo se ejecutan las instrucciones de la ISA y cómo se mueven los datos dentro del chip. Dos procesadores pueden compartir ISA (por ejemplo, AMD64 en Intel y AMD) y, sin embargo, tener un comportamiento y un rendimiento radicalmente distinto por culpa -o gracias- de su microarquitectura.

En ese diseño entran elementos como el tipo de unidad de control, si se usa microcódigo programable o lógica cableada; la jerarquía de memorias; la profundidad de la canalización; cuántas unidades funcionales trabajan en paralelo o si el procesador es capaz de ejecutar instrucciones fuera de orden y de manera especulativa.

Además, el diseñador debe elegir la profundidad del pipeline: desde CPUs simples sin segmentación, donde cada instrucción se procesa de principio a fin antes de empezar la siguiente, hasta diseños modernos con muchas etapas (fetch, decode, rename, dispatch, execute, write-back, retire…) que permiten tener en vuelo docenas de instrucciones al mismo tiempo.

Ligado a esto está el número y tipo de unidades de ejecución: ALUs para enteros, unidades de multiplicación, divisores, FPUs para coma flotante escalar y vectorial, AGUs (Address Generation Units) para calcular direcciones de memoria, unidades de salto, etc. Si hay varias unidades del mismo tipo hablamos de procesadores superescalares, capaces de despachar varias instrucciones por ciclo.

Sobre esta base se montan técnicas avanzadas como la ejecución especulativa, donde la CPU se adelanta a la resolución de un salto y ejecuta por anticipado instrucciones de una de las ramas. Si la predicción acierta, se gana tiempo; si falla, se descarta el trabajo realizado y se vacía el pipeline, con la consiguiente penalización.

La mayoría de CPUs de alto rendimiento actuales también utilizan ejecución fuera de orden (OoO). En lugar de respetar estrictamente el orden del programa, el procesador reordena internamente las instrucciones y ejecuta antes aquellas cuyos datos ya están listos, evitando ciclos muertos mientras otras esperan a la memoria o al resultado de operaciones previas.

Para que todo esto funcione sin violar la semántica del programa se recurre al renombre de registros. El compilador ve un conjunto limitado de registros lógicos, pero la microarquitectura los traduce a un banco mayor de registros físicos, asignando dinámicamente nuevos destinos para romper dependencias falsas y permitir más paralelismo.

Por último, el diseño puede apostar por añadir paralelismo a nivel de core e hilo. Eso incluye desde CPUs mononúcleo hasta chips con docenas o centenares de núcleos (manycore), sistemas multiprocesador con varios sockets interconectados por mallas de alta velocidad (Infinity Fabric, Intel Mesh, NVLink, etc.) y soporte de multihilo simultáneo (SMT) para que cada núcleo físico atienda dos o más hilos lógicos.

Compatibilidad, ISA y familias de microarquitecturas

Como la microarquitectura es solo una implementación concreta de la ISA, una misma ISA puede tener decenas de microarquitecturas distintas a lo largo de los años y entre fabricantes. Eso es justamente lo que ocurre con x86-64/AMD64 o con ARM.

Si miramos solo a AMD dentro de la ISA AMD64 encontramos familias tan distintas como K8/Hammer, K10, Bulldozer y toda la saga Zen (Zen, Zen+, Zen 2, Zen 3, Zen 4…). Todos ejecutan el mismo repertorio básico de instrucciones, pero su organización interna, sus cachés, su pipeline o su enfoque de ejecución en paralelo no tienen nada que ver.

Cuando cambiamos de ISA el salto de compatibilidad es absoluto. Un procesador basado en ARM A64 (como los Apple Silicon) no puede ejecutar binarios compilados para x86-64, y viceversa, salvo que intervenga una capa de traducción o emulación como Rosetta 2, QEMU o similares, con el coste de rendimiento correspondiente.

Incluso entre procesadores que comparten ISA no hay garantía de que todos soporten el mismo conjunto de instrucciones o extensiones. Un chip antiguo puede carecer de AVX2 o AVX-512, o un SoC ARM puede implementar solo un subconjunto de extensiones opcionales. Por eso un binario que tira de AVX-512 a saco puede no arrancar en una CPU que solo ofrece SSE4.

A la hora de compilar software, lo habitual es generar binarios genéricos para una ISA concreta (por ejemplo, x86-64 con SSE2 mínimo) sin explotar al máximo ninguna microarquitectura, de forma que el ejecutable funcione en el mayor número posible de CPUs. Sin embargo, si se compila con flags de afinado para una microarquitectura específica (-march=znver3, -mtune=skylake, etc.) se puede exprimir mucho más el rendimiento en esa familia concreta, a costa de perder compatibilidad con otras.

Licencias de ISA y propiedad intelectual del diseño

No solo el código de un programa está protegido por licencias: las ISAs y las microarquitecturas también son propiedad intelectual. Nadie puede, legalmente, clonar la ISA x86 o AMD64 sin una licencia, igual que no se puede copiar un diseño de CPU propietario sin permiso.

En el terreno de las ISAs hay tres grandes enfoques. Por un lado están las ISAs cerradas, donde el propietario controla férreamente quién puede implementar núcleos compatibles. El caso clásico es IA-32 (x86-32), históricamente en manos de Intel, que concedió licencias a AMD, VIA y otros, no sin batallas legales.

Algo similar ocurre con AMD64/x86-64, diseñada inicialmente por AMD y luego licenciada a Intel (que la llamó EM64T) mediante acuerdos cruzados. Otros jugadores, como Hygon en China, también han obtenido licencias para versiones concretas (por ejemplo, Zen 1 para el mercado chino).

Después tenemos ISAs con licenciamiento flexible, donde el dueño ofrece tanto licencias de la ISA como núcleos IP listos para integrar. ARM, SPARC u OpenPOWER encajan aquí: puedes pagar por usar Cortex A/M/R o Neoverse tal cual, o por una licencia que te permita diseñar tus propias microarquitecturas sobre la ISA, como hace Apple con sus M1/M2/M3 o Qualcomm con sus Kryo.

Y, finalmente, están las ISAs abiertas de estilo open source, donde cualquiera puede crear microarquitecturas compatibles sin pagar royalties por la ISA (aunque sí puede patentar o cerrar su propia implementación). RISC‑V es el mejor ejemplo: la ISA está bajo licencia BSD permisiva y hay desde núcleos completamente abiertos en Verilog o Chisel hasta diseños comerciales cerrados.

Además de la ISA, cada microarquitectura concreta (un núcleo Zen 4, un Cortex X4, un diseño de GPU, etc.) es un bloque de propiedad intelectual patentado o registrado. También aquí existen diseños abiertos, publicados como soft-cores en HDL para ser sintetizados en FPGAs o integrados en SoCs personalizados.

Profundizando en microarquitecturas modernas: el caso AMD Zen

Para ver cómo todo esto se traduce en rendimiento real, nada como destripar una familia concreta. AMD ha dado un giro brutal a su negocio gracias a Zen y sus sucesivas iteraciones, pasando de la etapa complicada de Bulldozer y los viejos FX a competir de tú a tú (y a veces mejor) con Intel en escritorio, servidor y portátil.

Tras el tropiezo de la estrategia AMD Fusion, la compañía se reestructuró y apostó por un diseño de alto rendimiento liderado, entre otros, por Jim Keller. El plan de Zen buscaba incrementar agresivamente el IPC (instrucciones por ciclo) respecto a Bulldozer, mejorar el rendimiento por vatio y recuperar terreno en single-core, donde Intel llevaba años de ventaja.

Uno de los cambios clave fue reforzar el front-end, la parte encargada de traer y preparar las instrucciones. Zen introdujo una caché de microoperaciones que guarda micro‑ops ya decodificadas, al estilo de lo que hicieron en su día algunas microarquitecturas Intel como Conroe. Bulldozer carecía de esto y dependía más de la jerarquía de caché de instrucciones clásica, lo que penalizaba su throughput.

El decodificador de Zen puede traducir hasta cuatro instrucciones CISC x86-64 por ciclo a micro‑ops RISC‑like. Esas micro‑ops pasan a una cola alimentada por el buffer de microoperaciones, que a su vez puede despachar hasta seis micro‑ops por ciclo hacia los planificadores del back‑end. Ahí empieza el baile de ejecución fuera de orden.

AMD separó claramente el camino de enteros y coma flotante. Por el lado de los enteros, desde la cola de micro‑ops se alimentan ALUs, AGUs y la lógica de load/store, capaz de realizar dos cargas de 16 bytes y un almacenamiento de 16 bytes por ciclo desde una L1D de 32 KB y 8 vías, con política write‑back.

El lado de la coma flotante y vectorial alimenta unidades FMAC y AVX. Con dos puertos de multiplicación y dos de suma, Zen puede ejecutar simultáneamente dos operaciones FMA de 128 bits o una operación AVX de 256 bits por ciclo de reloj. Este paralelismo a nivel de instrucción es una de las claves de su buen rendimiento en cargas de cómputo intensivo.

Jerarquía de caché, TLB y organización de memoria en Zen

La jerarquía de memorias en Zen está organizada en tres niveles de caché: L1 separada para instrucciones y datos, L2 privada por núcleo y L3 compartida. Aunque hereda la estructura básica de microarquitecturas anteriores, se han retocado tamaños, asociatividad y políticas.

La L1I (caché de instrucciones) ofrece 64 KB por núcleo, con 4 vías de asociatividad, lo que duplica las vías de Bulldozer por módulo y reduce conflictos. La L1D (caché de datos) pasa a 32 KB, 8 vías y política write‑back, frente a los 16 KB, 4 vías y write‑through de Bulldozer, mejorando mucho tanto la tasa de acierto como la eficiencia de escritura.

La caché L2 se implementa como 512 KB por núcleo y 8 vías, en lugar de los 2 MB 16‑way compartidos por módulo de la generación previa. La L3, por su parte, ofrece varios MB por conjunto de núcleos con 16 vías de asociatividad, actuando como último nivel compartido antes de ir a la DRAM.

En paralelo, Zen separa los TLB en ITLB (para instrucciones) y DTLB (para datos), cada uno con varios niveles y cientos de entradas, todos con protección por paridad. Esto reduce significativamente la latencia de traducción de direcciones virtual-físico, algo cada vez más crítico a medida que aumentan los tamaños de memoria.

Cuando se habla de que una caché es 2‑way, 4‑way, 8‑way, se está describiendo su asociatividad, muy relacionada con la idea de interleaving en memoria. Más asociatividad significa más formas distintas de almacenar un bloque de memoria en esa caché, reduciendo conflictos, a cambio de lógica algo más compleja y una ligera subida de latencia.

También es importante entender la diferencia entre write‑through y write‑back. En la primera, cada escritura actualiza a la vez caché y memoria principal, lo que simplifica la coherencia pero multiplica el tráfico. En la segunda, se escribe solo en caché y se marca la línea con un dirty bit; la DRAM solo se actualiza cuando esa línea se expulsa, ahorrando ancho de banda y mejorando el rendimiento a costa de una lógica un poco más elaborada.

Zen y Zen+: salto en IPC y eficiencia

Zen supuso para AMD un salto de IPC muy notable respecto a Bulldozer, gracias a la combinación de mejor front‑end, mejor predictor de saltos, más unidades de ejecución, SMT en lugar de CMT (cada núcleo completo maneja dos hilos, en lugar de compartir parte de la FPU entre dos núcleos lógicos) y una jerarquía de cachés mucho más sensata.

Además del diseño, AMD se benefició de procesos de fabricación más avanzados con FinFET y nodos más pequeños, que permiten aumentar la densidad de transistores, reducir el consumo a igual rendimiento o subir frecuencias manteniendo TDPs razonables (curva voltaje-frecuencia). Este balance de rendimiento por vatio fue crucial para volver a ser competitivos en portátiles y servidores.

La transición de Bulldozer a Zen también trajo colas de retirada (retire queues) más largas, planificadores de instrucciones de mayor tamaño, mayor ancho de banda interno, predicción de saltos con técnicas basadas incluso en redes neuronales simples y un SMT capaz de exprimir mejor las unidades de ejecución disponibles.

En este contexto aparece Zen+, que podríamos ver como el equivalente a un «tick» en la vieja estrategia Tick‑Tock de Intel: mismo diseño base que Zen, pero fabricado en un nodo más pulido, con mejoras de frecuencia, pequeñas reducciones de latencia y ajustes de timings internos. No es una revolución de arquitectura, pero sí un refinamiento que se traduce en unos cuantos puntos extra de rendimiento.

Zen 2: chiplets, AVX2 completo y refinamiento profundo

Con Zen 2, AMD ya no se limita a un pulido de proceso: introduce cambios sustanciales de microarquitectura y estrena masivamente su estrategia de chiplets. En lugar de un gran die monolítico, divide el diseño en varios dies de cómputo (CCD) más pequeños de 7 nm y un die de I/O separado en 12 nm encargado de la memoria, PCIe y la interconexión.

Este enfoque de chiplets mejora el yield por oblea (es más fácil fabricar dies pequeños sin defectos), reduce costes y facilita escalar el número de núcleos: basta con añadir más CCDs para llegar a 16, 32 o más cores en EPYC y Threadripper. El precio a pagar es una comunicación interna algo más compleja y dependiente de la interconexión Infinity Fabric, que AMD ha ido puliendo generación tras generación.

A nivel de rendimiento bruto, AMD habla para Zen 2 de alrededor de un +15% de IPC respecto a Zen+ a igual frecuencia y de una mejora global de rendimiento por vatio que puede rondar el +75% frente a la primera Zen cuando se combinan las mejoras de diseño y de proceso.

En el back‑end vectorial, Zen 2 da el paso que le faltaba: ofrece soporte completo de AVX2 a 256 bits en una sola micro‑op, sin dividir las instrucciones en dos operaciones de 128 bits como ocurría en Zen/Zen+. Esto implica que las unidades de ejecución vectorial son ya realmente de 256 bits y pueden procesar cargas AVX2 a plena velocidad con mucha menor penalización de frecuencia que en otros diseños.

También se refuerza la caché de micro‑ops, que pasa a 4K entradas (el doble), aprovechando parte del área liberada al reducir la L1I a la mitad pero doblando su asociatividad de 4 a 8 vías. Simulaciones internas llevaron a AMD a la conclusión de que, para la mayoría de cargas reales, compensa más tener una uop cache más grande que una L1I más gorda.

La L3 por bloque de núcleos se duplica en capacidad, lo que ayuda a reducir fallos de último nivel aunque la latencia de acceso suba de ~35 a ~40 ciclos. Para mitigar este efecto, Zen 2 mejora los anchos de banda de carga y almacenamiento y refina la política de prefetch.

Otro frente importante es el predictor de saltos. Zen 2 utiliza un predictor TAGE (TAgged GEometric) con más de 7K entradas, capaz de aprovechar historiales de longitud variable y entradas etiquetadas. Esto reduce aliasing entre ramas distintas y, según AMD, recorta en torno a un 30% el número de predicciones erróneas en comparación con el esquema anterior, algo que repercute directamente en menos vaciados de pipeline y más IPC.

Back‑end de Zen 2: AGUs, buffers y latencias ajustadas

En el back‑end entero, Zen 2 sigue despachando hasta seis micro‑ops por ciclo desde el buffer de reordenamiento, que se amplía hasta unas 224 entradas (frente a las 192 de Zen). Las unidades de programación se reparten en cuatro colas para ALUs de 16 entradas cada una y una cola para AGUs de 28 entradas.

El número de AGUs (Address Generation Units) pasa de dos a tres, aunque no todas son idénticas: dos de ellas pueden manejar tanto cargas como escrituras, mientras que la tercera se especializa en operaciones de almacenamiento. Esta distribución responde a perfiles típicos de software, donde las cargas suelen ser más frecuentes y críticas que los stores.

En el plano de la coma flotante, el back‑end puede aceptar cuatro micro‑ops por ciclo hacia sus unidades vectoriales FMA de 256 bits, apoyadas en un archivo de registros físicos de 160 entradas. Las rutas de carga/almacenamiento de 256 bits se han mejorado para poder alimentar estas unidades a ritmo sostenido en workloads vectoriales pesados.

Zen 2 también ajusta las latencias de ciertas operaciones: por ejemplo, la multiplicación en coma flotante reduce su latencia de 4 a 3 ciclos, lo que ayuda a bucles muy apretados de cálculo numérico. Y, en general, hay un conjunto de pequeñas optimizaciones repartidas por todo el pipeline que suman ese plus de IPC que se ve en benchmarks sintéticos y aplicaciones reales.

En cuanto a la jerarquía interna por grupos de núcleos, AMD utiliza el concepto de CCX (Core CompleX): un bloque de 4 núcleos que comparten una misma caché L3 (16 MB en Zen 2). Este tamaño extra implica algo más de latencia, pero a cambio reduce la tasa de fallos, especialmente en aplicaciones con working sets grandes.

Para orientarse, podemos recordar cifras aproximadas de latencia interna: alrededor de 4 ciclos para L1, unos 12 para L2 y en torno a 40 ciclos para L3. La clave está en mantener el máximo de datos posibles en L1/L2 y reducir el tráfico hacia L3 y memoria DRAM, algo en lo que la microarquitectura y los compiladores juegan juntos.

Infinity Fabric: el pegamento de los chiplets y su impacto en rendimiento

Una pieza que no siempre se asocia a la microarquitectura, pero que en Zen 2 y posteriores es vital, es Infinity Fabric. Este bus propietario actúa como «autopista» de comunicación entre CCXs, CCDs, el die de I/O, la memoria y, en general, entre todos los bloques del SoC.

Infinity Fabric es una evolución de HyperTransport, aquel bus de alta velocidad que AMD promovió hace años y que usaron también terceros como NVIDIA, Cisco, Sun u otros miembros del consorcio. IF hereda la filosofía de enlaces punto a punto escalables, pero adaptados a las necesidades de los SoC modernos y de la interconexión CPU-GPU.

En Zen 2, AMD introduce IF2, con soporte para PCIe 4.0 y un bus interno de 512 bits entre CCXs, el doble que la primera versión. Esto se traduce en más ancho de banda efectivo y una mejora de eficiencia que AMD cifra en torno al 27% respecto a IF1, ayudando a que la penalización de ir de un chiplet a otro no sea dramática.

Además, el reloj de Infinity Fabric se desacopla parcialmente del de la DRAM, permitiendo que la memoria principal pueda escalar a frecuencias superiores en determinados escenarios sin forzar necesariamente a IF a seguir el mismo ritmo, algo que ofrece más margen de ajuste fino a entusiastas y diseñadores de sistemas.

En procesadores de servidor como EPYC, con cuatro o más chiplets de cómputo, Infinity Fabric es lo que hace posible conectar todos los dados entre sí con topologías casi completas (rotaciones de 180º, enlaces directos, etc.), alcanzando anchos de banda die‑to‑die que pueden superar fácilmente los 150 GB/s bidireccionales dependiendo de la velocidad de la DDR empleada.

La combinación de una microarquitectura sólida en cada núcleo, un diseño escalable mediante chiplets y una interconexión suficientemente rápida permite a AMD montar CPUs de 32, 64 o más núcleos con un rendimiento extraordinario en cargas altamente paralelas, manteniendo al mismo tiempo un IPC competitivo por hilo.

Al final, cuando comparas procesadores en benchmarks de juegos, renderizado 3D, compilación masiva o simulación científica, las cifras de GHz y de número de núcleos solo cuentan una parte de la historia. Lo que realmente marca la diferencia es cómo la microarquitectura orquesta la ejecución interna, cómo aprovecha o desperdicia cada ciclo de reloj y qué compromisos ha tomado el fabricante entre latencia, ancho de banda, consumo y complejidad.