💻 computer science

85.30 GFLOPS Single-Core FP32 Matrix Multiplication on AMD Zen 3: A Systematic Study of Cache Blocking, Register Blocking, FMA Chaining, and On-the-Fly Packing

Este artículo presenta un estudio de optimización sistemática sobre la microarquitectura AMD Zen 3 que logra 85.30 GFLOPS en la multiplicación de matrices FP32 de un solo núcleo mediante la evaluación de 28 configuraciones distintas de bloqueo de caché/registro, encadenamiento FMA y empaquetado sobre la marcha, identificando finalmente un diseño campeón que alcanza el 63.5% del rendimiento pico teórico al tiempo que introduce un modelo predictivo para optimizaciones futuras.

Autores originales: Lucas Lima Freitag

Publicado 2026-07-15

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Lucas Lima Freitag

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando mover un enorme montón de arena (datos) de un lado a otro de un almacén gigante, pero tienes que hacerlo usando un pequeño y superrápido brazo robótico (el procesador). El objetivo es mezclar la arena con una fórmula especial (multiplicación de matrices) lo más rápido posible. Este artículo es un registro detallado del cuaderno de bitácora de un investigador, Lucas, intentando hacer que ese brazo robótico se mueva lo más rápido que humanamente sea posible en un tipo específico de chip informático llamado AMD Zen 3.

El Gran Objetivo: ¿Qué tan rápido es rápido?

El brazo robótico tiene una velocidad máxima teórica de 134.4 GFLOPS (eso son 134.4 mil millones de operaciones matemáticas por segundo). Piensa en esto como el límite de velocidad en una autopista. Lucas quería ver qué tan cerca podía llegar a ese límite de velocidad sin construir un coche nuevo, simplemente ajustando el motor.

Después de probar 28 estrategias de conducción diferentes, encontró una configuración "campeona" (llamada MX24) que alcanzó los 85.30 GFLOPS. Eso es aproximadamente el 63.5% de la velocidad máxima. No es un 100% perfecto, pero es un salto enorme desde la línea de salida, que era un método lento y torpe que funcionaba a solo 1.51 GFLOPS. De hecho, su mejor método fue 57 veces más rápido que la versión básica no optimizada.

La Estrategia Ganadora: La Danza de "4 Filas, Cadena de 4"

Para lograr esta velocidad, Lucas tuvo que descubrir cómo organizar la arena y los movimientos del robot. Aquí están los movimientos clave que descubrió:

1. El truco de empaquetado "sobre la marcha"
Imagina que la arena está almacenada en una cuadrícula donde tienes que caminar diagonalmente para agarrar el siguiente grano. Eso es lento y agotador. Lucas descubrió que copiar un pequeño trozo de la arena en una línea recta y ordenada justo antes de que el robot la necesite (llamado empaquetado sobre la marcha o on-the-fly packing) fue el movimiento mágico. Es como tener a un ayudante corriendo por delante y apilando los ladrillos en una fila perfecta para que el robot pueda simplemente agarrarlos uno tras otro sin tropezar. Esto superó al viejo método de simplemente agarrarlos tal como estaban, e incluso fue mejor que reorganizar todo el almacén de antemano.

2. El apilamiento de "4 Filas"
El robot tiene un número limitado de manos (registros) para sostener la arena mientras trabaja. Lucas probó sosteniendo 2 filas de arena, luego 4, luego 8.

2 Filas: Demasiado poco. El robot tenía que detenerse y buscar nueva arena con demasiada frecuencia.
8 Filas: ¡Demasiado! Sus manos estaban tan llenas que tenía que dejar caer arena al suelo (memoria) y recogerla de nuevo constantemente. Esto fue un desastre.
4 Filas: El punto ideal. Aunque el robot tuvo que dejar caer algunos granos al suelo y recogerlos de nuevo (un proceso llamado "derrame" o spilling), el trabajo extra valió la pena porque podía procesar más arena a la vez. Este único cambio hizo que el robot fuera un 59% más rápido que el método de 2 filas.

3. El ritmo de "Cadena de 4"
El brazo del robot tarda 4 segundos (ciclos) en terminar un solo movimiento matemático antes de poder empezar el siguiente sobre la misma pieza de arena. Si el robot hiciera un solo movimiento y esperara, estaría ocioso durante 3 segundos.
Lucas descubrió que si el robot sostenía 4 pilas diferentes de arena en sus manos y trabajaba en ellas en un bucle (Cadena-4), podía mantener el brazo moviéndose constantemente. Mientras una pila de arena se estaba "cocinando", él trabajaba en las otras. Esto encajaba perfectamente con el tiempo de cocción de 4 segundos del robot, manteniendo el motor zumbando a toda velocidad.

Lo que No Funcionó (La lista de "No lo hagas")

A veces, lo que crees que debería funcionar, en realidad lo empeora. Lucas probó algunas ideas populares y descubrió que eran terribles para este robot específico:

El error del "Pre-fetch": La gente suele decirle a los robots que "miren hacia adelante" y agarren el siguiente grano de arena antes de que lo necesiten. Lucas probó esto, pero los ojos integrados del robot ya eran tan buenos viendo el patrón que los comandos adicionales de "mirar hacia adelante" solo estorbaron. Esto ralentizó al robot aproximadamente un 8%.
El vertido "No Temporal": Existe un truco donde le dices al robot que vierta la arena directamente en el suelo sin ponerla en un contenedor primero. Esto funciona muy bien si solo estás tirando basura. Pero aquí, el robot tiene que mezclar la arena, lo que significa que tiene que recogerla de nuevo. Verterla directamente hizo que el robot tropezara con sus propios pies, desplomando su velocidad a unos patéticos 1.24 GFLOPS.
La sobrecarga de "8 Filas": Como se mencionó, intentar sostener 8 filas de arena causó que el robot dejara caer tanta arena que pasaba más tiempo recogiéndola que moviéndola.

¿Qué tan seguros estamos?

El artículo tiene mucha confianza en estos números porque fueron medidos, no solo adivinados. Lucas ejecutó el código 15 veces para cada estrategia, descartó las ejecuciones más rápidas y más lentas (para evitar glitches extraños de la computadora) y promedió el resto. También verificó las matemáticas contra una versión simple y lenta para asegurarse de que la versión rápida no hiciera trampa.

Incluso construyó un modelo de "pre-filtro" matemático —una especie de bola de cristal— para predecir qué tan rápida sería una estrategia antes de ejecutarla realmente. Esta bola de cristal fue bastante buena, situándose dentro de un 11.3% de la velocidad real para la mayoría de las estrategias. Tendió a ser un poco conservadora, prediciendo que la mejor estrategia sería de 78.1 GFLOPS, pero cuando realmente la ejecutaron, alcanzó los 85.30 GFLOPS.

La Conclusión

Este artículo demuestra que no necesitas ser un mago escribiendo código en "lenguaje ensamblador" (la lengua nativa del robot) para obtener una velocidad increíble. Al usar herramientas estándar (intrínsecos de C++) y ajustar cuidadosamente los "pasos de baile" (bloqueo, encadenamiento y empaquetado), puedes lograr que tu computadora funcione al 63.5% de su velocidad máxima teórica.

¿La lección principal? No adivines. Lo que funciona para un tipo de robot (o chip de computadora) puede romper otro. Lucas probó 28 combinaciones diferentes para encontrar la que funcionaba, demostrando que, a veces, los trucos "obvios" (como mirar hacia adelante o verter directamente) son en realidad los movimientos equivocados.

Título: 85.30 GFLOPS de multiplicación de matrices FP32 de un solo núcleo en AMD Zen 3: Un estudio sistemático de bloqueo de caché, bloqueo de registros, encadenamiento de FMA y empaquetado sobre la marcha

Planteamiento del problema
La multiplicación de matrices (GEMM) es una operación fundamental en la computación científica y el aprendizaje automático, pero alcanzar el rendimiento máximo en procesadores modernos requiere navegar por un complejo panorama de jerarquías de memoria, archivos de registros y restricciones de segmentación (pipeline). Si bien las bibliotecas como BLIS y OpenBLAS proporcionan núcleos altamente optimizados, existe la necesidad de comprender sistemáticamente cómo interactúan técnicas de optimización específicas en microarquitecturas contemporáneas, particularmente en AMD Zen 3. Este artículo aborda el desafío de maximizar el rendimiento de punto flotante de un solo núcleo para el kernel de GEMM ( $C = \alpha AB + \beta C$ ) en el procesador AMD Ryzen 5 5500, con el objetivo de acercarse al rendimiento pico teórico sin depender de código ensamblador escrito a mano o bibliotecas propietarias externas.

Metodología
El estudio emplea una exploración sistemática de un espacio de diseño que comprende 28 modelos de optimización distintos (MX00–MX28) dirigidos a la microarquitectura AMD Zen 3. La metodología consiste en:

Análisis de la arquitectura objetivo: Examen detallado del núcleo Zen 3, específicamente su latencia de FMA de 4 ciclos, puertos FMA duales de 256 bits, 16 registros arquitectónicos YMM y una jerarquía de caché de tres niveles (32 KB L1, 512 KB L2, 16 MB L3).
Dimensiones de optimización: Los autores varían combinatoriamente técnicas clave:
- Bloqueo de caché (Cache Blocking): Tiling de tres niveles (L1, L2, L3) con tamaños de bloque variables ( $B_I, B_J, B_K$ ).
- Bloqueo de registros (Register Blocking): Partición de la matriz acumuladora $C$ en esquemas de 2 filas, 4 filas y 8 filas para utilizar los 16 registros YMM disponibles.
- Encadenamiento de FMA (FMA Chaining): Implementación de longitudes de cadena de 1 a 6 para ocultar la latencia de FMA de 4 ciclos.
- Estrategias de empaquetado (Packing Strategies): Comparación de sin empaquetado, transposición de matriz explícita ( $B^T$ ) y empaquetado de $B$ sobre la marcha (on-the-fly).
- Técnicas auxiliares: Alineación de memoria, prelectura de software (software prefetching) y almacenes no temporales (non-temporal stores).
Configuración experimental: Los experimentos se realizaron en un solo núcleo de un AMD Ryzen 5 5500 funcionando a 4.2 GHz. El código fue escrito en C++ utilizando intrínsecos y compilado con GCC 12.2 con el flag -O3. El rendimiento se midió para matrices cuadradas de dimensión $N=2048$ utilizando tipos de datos FP32.
Modelo predictivo: Se desarrolló un modelo de pre-filtro matemático para estimar el rendimiento a priori basado en penalizaciones de segmentación, presión de registros y tasas de fallos de caché, calibrado contra los 28 modelos experimentales.

Contribuciones clave y resultados
El artículo presenta una configuración campeona, MX24, que alcanza 85.30 GFLOPS, lo que representa el 63.5% del pico teórico de un solo núcleo de 134.4 GFLOPS. Este resultado es aproximadamente 57 veces más rápido que una implementación ingenua de triple bucle.

Configuración óptima: El modelo ganador utiliza un bloque de registro de 4 filas, encadenamiento FMA chain4 (que coincide con la latencia de 4 ciclos), empaquetado de B sobre la marcha y un tamaño de tile profundo de $B_K = 256$ (que cabe dentro de la caché L2).
Hallazgos contraintuitivos:
- Derrame de registros (Register Spilling): A pesar de requerir 16 derrames de registros (se necesitan 32 registros lógicos frente a 16 físicos), el esquema de 4 filas superó al esquema de 2 filas libre de derrames en un 59%. El compilador programó eficientemente las operaciones de derrame durante las burbujas de la segmentación, y la mayor reutilización de los elementos de $A$ compensó la sobrecarga de memoria.
- Prelectura de software (Software Prefetching): Contrario a la intuición común, la prelectura de software degradó el rendimiento en aproximadamente un 8%, ya que el prelector de hardware de Zen 3 ya era altamente efectivo para los patrones de acceso de streaming de GEMM.
- Almacenes no temporales (Non-Temporal Stores): El uso de almacenes no temporales para la matriz $C$ causó un colapso catastrófico de rendimiento a 1.24 GFLOPS porque GEMM es una operación de lectura-modificación-escritura, y saltarse la caché invalidó los datos necesarios para las cargas subsiguientes.
- Eficiencia de empaquetado: El empaquetado sobre la marcha superó a la transposición completa de la matriz al evitar la contaminación de la caché durante la fase de configuración, proporcionando al mismo tiempo un acceso contiguo a la memoria similar a la transposición.
Modelo predictivo: El modelo de pre-filtro matemático logró un Error Porcentual Absoluto Medio (MAPE) del 11.3% a través del espacio de diseño, identificando con éxito configuraciones de alto rendimiento con un sesgo conservador.

Significancia y Reivindicaciones
Los autores afirman que este trabajo proporciona una referencia reproducible para la optimización de GEMM de un solo núcleo en microarquitecturas x86-64 contemporáneas. La principal significancia radica en demostrar que el código vectorizado cuidadosamente ajustado usando intrínsecos de C++ puede acercarse a 2× del techo de la línea de techo (roofline ceiling) sin dependencias de bibliotecas externas o ensamblador escrito a mano.

El artículo enfatiza que la optimización combinatoria sistemática produce mejores resultados que confiar en heurísticas generales, como lo demuestra el fallo de técnicas como la prelectura de software y los almacenes no temporales en este contexto específico. El resultado de 85.30 GFLOPS es competitivo con las bibliotecas maduras y optimizadas por proveedores (como AMD AOCL e Intel MKL) en hardware comparable, validando la efectividad de la plantilla de optimización descrita (4 filas, chain4, empaquetado sobre la marcha) para arquitecturas x86-64 con soporte para AVX2/FMA. El trabajo también destaca el papel crítico de la calidad del compilador, señalando que GCC 12.2 produjo un código significativamente mejor que Microsoft Visual C++ para estos intrínsecos específicos.

El Gran Objetivo: ¿Qué tan rápido es rápido?

La Estrategia Ganadora: La Danza de "4 Filas, Cadena de 4"

Lo que No Funcionó (La lista de "No lo hagas")

¿Qué tan seguros estamos?

La Conclusión

Más como este