💻 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 artigo apresenta um estudo de otimização sistemática sobre a microarquitetura AMD Zen 3 que alcança 85,30 GFLOPS em multiplicação de matrizes FP32 de núcleo único ao avaliar 28 configurações distintas de bloqueio de cache/registrador, encadeamento de FMA e empacotamento em tempo real, identificando finalmente um design campeão que atinge 63,5% do desempenho de pico teórico ao mesmo tempo em que introduz um modelo preditivo para otimizações futuras.

Autores originais: Lucas Lima Freitag

Publicado 2026-07-15

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Lucas Lima Freitag

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando mover uma pilha enorme de areia (dados) de um lado para o outro de um armazém gigante usando um braço robótico minúsculo e superveloz (o processador). O objetivo é misturar a areia com uma fórmula especial (multiplicação de matrizes) o mais rápido possível. Este artigo é um diário detalhado de um pesquisador, Lucas, tentando fazer esse braço robótico se mover o mais rápido que humanamente possível em um tipo específico de chip de computador chamado AMD Zen 3.

O Grande Objetivo: O que é Rápido?

O braço robótico tem uma velocidade máxima teórica de 134,4 GFLOPS (isso são 134,4 bilhões de operações matemáticas por segundo). Pense nisso como o limite de velocidade em uma rodovia. Lucas queria ver o quão perto ele poderia chegar desse limite de velocidade sem construir um carro novo, apenas ajustando o motor.

Após testar 28 diferentes estratégias de condução, ele encontrou uma configuração "campeã" (chamada MX24) que atingiu 85,30 GFLOPS. Isso é cerca de 63,5% da velocidade máxima. Não é um 100% perfeito, mas é um salto enorme em relação à linha de partida, que era um método lento e desajeitado rodando a apenas 1,51 GFLOPS. Na verdade, seu melhor método foi 57 vezes mais rápido do que a versão básica não otimizada.

A Estratégia Vencedora: A Dança "4-Linhas, Cadeia-4"

Para obter essa velocidade, Lucas teve que descobrir como organizar a areia e os movimentos do robô. Aqui estão os movimentos principais que ele descobriu:

1. O Truque de Empacotamento "On-the-Fly"
Imagine que a areia está armazenada em uma grade onde você tem que caminhar diagonalmente para pegar o próximo grão. Isso é lento e cansativo. Lucas descobriu que copiar um pequeno pedaço da areia em uma linha reta e organizada logo antes de o robô precisar dela (chamado de empacotamento on-the-fly) foi o movimento mágico. É como ter um ajudante correndo à frente e empilhando os tijolos em uma fileira perfeita para que o robô possa apenas pegá-los um após o outro sem tropeçar. Isso superou o método antigo de apenas pegá-los como estavam, e foi ainda melhor do que reorganizar o armazém inteiro antecipadamente.

2. O Empilhamento de "4 Linhas"
O robô tem um número limitado de mãos (registradores) para segurar a areia enquanto trabalha. Lucas tentou segurar 2 linhas de areia, depois 4, depois 8.

2 Linhas: Poucas. O robô tinha que parar e buscar nova areia com muita frequência.
8 Linhas: Muitas! As mãos do robô estavam tão cheias que ele tinha que derrubar areia no chão (memória) e pegá-la novamente o tempo todo. Isso foi um desastre.
4 Linhas: O ponto ideal. Embora o robô tivesse que derrubar alguns grãos no chão e pegá-los novamente (um processo chamado "spill" ou transbordamento), o trabalho extra valeu a pena porque ele podia processar mais areia de uma vez. Essa única mudança tornou o robô 59% mais rápido do que o método de 2 linhas.

3. O Ritmo da "Cadeia-4"
O braço do robô leva 4 segundos (ciclos) para terminar um único movimento matemático antes de poder começar o próximo movimento na mesma peça de areia. Se o robô fizesse apenas um movimento e esperasse, ele ficaria ocioso por 3 segundos.
Lucas descobriu que, se o robô segurasse 4 pilhas diferentes de areia em suas mãos e trabalhasse nelas em um loop (Cadeia-4), ele poderia manter o braço se movendo constantemente. Enquanto uma pilha estava "cozinhando", ele trabalhava nas outras. Isso combinava perfeitamente com o tempo de cozimento de 4 segundos do robô, mantendo o motor funcionando em velocidade máxima.

O Que Não Funcionou (A Lista do "Não Faça Isso")

Às vezes, o que você acha que deve funcionar, na verdade, piora as coisas. Lucas testou algumas ideias populares e descobriu que elas eram terríveis para este robô específico:

O Erro do "Pre-fetch": As pessoas costumam dizer aos robôs para "olhar à frente" e pegar o próximo grão de areia antes de precisarem dele. Lucas tentou isso, mas os olhos integrados do robô já eram tão bons em ver o padrão que os comandos extras de "olhar à frente" apenas atrapalharam. Isso reduziu a velocidade do robô em cerca de 8%.
O Descarte "Não-Temporal": Existe um truque onde você diz ao robô para jogar a areia diretamente no chão sem colocá-la em um recipiente primeiro. Isso funciona bem se você estiver apenas jogando lixo fora. Mas aqui, o robô tem que misturar a areia, o que significa que ele tem que pegá-la novamente. O descarte direto fez o robô tropeçar nos próprios pés, derrubando sua velocidade para uns patéticos 1,24 GFLOPS.
A Sobrecarga de "8 Linhas": Como mencionado, tentar segurar 8 linhas de areia fez com que o robô derrubasse tanta areia que ele passava mais tempo pegando-a do que movendo-a.

O Quão Certos Estamos?

O artigo é muito confiante nesses números porque eles foram medidos, não apenas adivinhados. Lucas executou o código 15 vezes para cada estratégia, descartou as execuções mais rápidas e as mais lentas (para evitar glitches estranhos do computador) e fez a média das demais. Ele também verificou a matemática contra uma versão simples e lenta para garantir que a versão rápida não estivesse trapaceando.

Ele até construiu um modelo de "pré-filtro" matemático — uma espécie de bola de cristal — para prever a velocidade de uma estratégia antes mesmo de executá-la. Essa bola de cristal foi muito boa, ficando dentro de 11,3% da velocidade real para a maioria das estratégias. Ela tendia a ser um pouco conservadora, prevendo que a melhor estratégia seria de 78,1 GFLOPS, mas quando eles a executaram de fato, ela atingiu 85,30 GFLOPS.

A Conclusão

Este artigo prova que você não precisa ser um mago escrevendo código em "linguagem assembly" (a língua nativa do robô) para obter uma velocidade incrível. Ao usar ferramentas padrão (intrínsecos de C++) e ajustar cuidadosamente os "passos de dança" (bloqueio, encadeamento e empacotamento), você pode fazer seu computador rodar a 63,5% de sua velocidade máxima teórica.

A lição principal? Não adivinhe. O que funciona para um tipo de robô (ou chip de computador) pode quebrar outro. Lucas testou 28 combinações diferentes para encontrar aquela que funcionava, mostrando que, às vezes, os truques "óbvios" (como olhar à frente ou descartar diretamente) são, na verdade, os movimentos errados.

Título: 85,30 GFLOPS de Multiplicação de Matrizes FP32 de Núcleo Único em AMD Zen 3: Um Estudo Sistemático de Bloqueio de Cache, Bloqueio de Registradores, Encadeamento de FMA e Empacotamento On-the-Fly

Definição do Problema
A multiplicação de matrizes (GEMM) é uma operação fundamental na computação científica e no aprendizado de máquina, mas alcançar o desempenho de pico em processadores modernos exige navegar por um cenário complexo de hierarquias de memória, arquivos de registradores e restrições de pipeline. Embora bibliotecas como BLIS e OpenBLAS forneçam kernels altamente otimizados, há a necessidade de compreender sistematicamente como técnicas de otimização específicas interagem em microarquiteturas contemporâneas, particularmente a AMD Zen 3. Este artigo aborda o desafio de maximizar o throughput de ponto flutuante de núcleo único para o kernel GEMM ( $C = \alpha AB + \beta C$ ) no processador AMD Ryzen 5 5500, visando aproximar-se do desempenho de pico teórico sem depender de assembly codificado à mão ou bibliotecas proprietárias externas.

Metodologia
O estudo emprega uma exploração sistemática de um espaço de design composto por 28 modelos de otimização distintos (MX00–MX28) visando a microarquitetura AMD Zen 3. A metodologia envolve:

Análise da Arquitetura Alvo: Exame detalhado do núcleo Zen 3, especificamente sua latência de FMA de 4 ciclos, portas FMA duplas de 256 bits, 16 registradores arquiteturais YMM e hierarquia de cache de três níveis (32 KB L1, 512 KB L2, 16 MB L3).
Dimensões de Otimização: Os autores variam combinatoriamente as principais técnicas:
- Bloqueio de Cache (Cache Blocking): Tiling de três níveis (L1, L2, L3) com variações nos tamanhos de bloco ( $B_I, B_J, B_K$ ).
- Bloqueio de Registrador (Register Blocking): Particionamento da matriz acumuladora $C$ em esquemas de 2 linhas, 4 linhas e 8 linhas para utilizar os 16 registradores YMM disponíveis.
- Encadeamento de FMA (FMA Chaining): Implementação de comprimentos de cadeia de 1 a 6 para ocultar a latência de 4 ciclos do FMA.
- Estratégias de Empacotamento (Packing Strategies): Comparação entre nenhum empacotamento, transposição explícita de matriz ( $B^T$ ) e empacotamento de $B$ on-the-fly.
- Técnicas Auxiliares: Alinhamento de memória, prefetching de software e stores não-temporais.
Configuração Experimental: Os experimentos foram conduzidos em um único núcleo de um AMD Ryzen 5 5500 operando a 4,2 GHz. O código foi escrito em C++ usando intrinsics e compilado com GCC 12.2 em -O3. O desempenho foi medido para matrizes quadradas de dimensão $N=2048$ utilizando tipos de dados FP32.
Modelagem Preditiva: Um modelo de pré-filtro matemático foi desenvolvido para estimar o desempenho a priori com base em penalidades de pipeline, pressão de registradores e taxas de falha de cache, calibrado contra os 28 modelos experimentais.

Principais Contribuições e Resultados
O artigo apresenta uma configuração campeã, MX24, que atinge 85,30 GFLOPS, representando 63,5% do pico teórico de núcleo único de 134,4 GFLOPS. Este resultado é aproximadamente 57× mais rápido do que uma implementação ingênua de triplo laço (triple-loop).

Configuração Ótima: O modelo vencedor utiliza um bloco de registrador de 4 linhas, encadeamento de FMA chain4 (correspondendo à latência de 4 ciclos), empacotamento de B on-the-fly, e um tamanho de tile profundo de $B_K = 256$ (encaixando-se no cache L2).
Descobertas Contraintuitivas:
- Spill de Registrador (Register Spilling): Apesar de exigir 16 spills de registradores (3ando 32 registradores lógicos necessários vs. 16 físicos), o esquema de 4 linhas superou o esquema de 2 linhas livre de spills em 59%. O compilador escalonou eficientemente as operações de spill durante os bubbles do pipeline, e o aumento no reúso dos elementos de $A$ compensou o overhead de memória.
- Software Prefetching: Contrariando a intuição comum, o prefetching de software degradou o desempenho em aproximadamente 8%, pois o prefetcher de hardware do Zen 3 já era altamente eficaz para os padrões de acesso de streaming da GEMM.
- Stores Não-Temporais: O uso de stores não-temporais para a matriz $C$ causou um colapso catastrófico de desempenho para 1,24 GFLOPS, pois a GEMM é uma operação de leitura-modificação-escrita, e o bypass do cache invalidou os dados necessários para cargas subsequentes.
- Eficiência de Empacotamento: O empacotamento on-the-fly superou a transposição total de matriz ao evitar a poluição do cache durante a fase de configuração, ao mesmo tempo em que proporcionou um acesso à memória contíguo semelhante à transposição.
Modelo Preditivo: O modelo de pré-filtro matemático alcançou um Erro Percentual Absoluto Médio (MAPE) de 11,3% em todo o espaço de design, identificando com sucesso configurações de alto desempenho com um viés conservador.

Significância e Alegações
Os autores alegam que este trabalho fornece uma referência reproduzível para a otimização de GEMM de núcleo único em microarquiteturas x86-64 contemporâneas. A principal significância reside em demonstrar que código vetorizado cuidadosamente ajustado à mão usando intrins C++ pode se aproximar de dentro de 2× do teto de roofline sem dependências de bibliotecas externas ou assembly escrito à mão.

O artigo enfatiza que a otimização combinatória sistemática produz melhores resultados do que confiar em heurísticas gerais, como evidenciado pelo fracasso de técnicas como software prefetching e stores não-temporais neste contexto específico. O resultado de 85,30 GFLOPS é competitivo com bibliotecas maduras e otimizadas por fabricantes (como AMD AOCL e Intel MKL) em hardware comparável, validando a eficácia do template de otimização descrito (4-row, chain4, empacotamento on-the-fly) para arquiteturas x86-64 com suporte a AVX2/FMA. O trabalho também destaca o papel crítico da qualidade do compilador, observando que o GCC 12.2 produziu código significativamente melhor que o Microsoft Visual C++ para esses intrins específicos.

O Grande Objetivo: O que é Rápido?

A Estratégia Vencedora: A Dança "4-Linhas, Cadeia-4"

O Que Não Funcionou (A Lista do "Não Faça Isso")

O Quão Certos Estamos?

A Conclusão

Mais como este