💻 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

Dit artikel presenteert een systematische optimalisatiestudie naar de AMD Zen 3-microarchitectuur die 85,30 GFLOPS bereikt in single-core FP32-matrixvermenigvuldiging door 28 afzonderlijke configuraties van cache/register blocking, FMA-chaining en on-the-fly packing te evalueren, waarbij uiteindelijk een kampioendesign wordt geïdentificeerd dat 63,5% van de theoretische piekprestatie bereikt terwijl het een predictief model introduceert voor toekomstige optimalisaties.

Oorspronkelijke auteurs: Lucas Lima Freitag

Gepubliceerd 2026-07-15

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Lucas Lima Freitag

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme hoop zand (data) van de ene kant van een gigantische loods naar de andere kant wilt verplaatsen, maar je moet dit doen met een piepkleine, supersnelle robotarm (de processor). Het doel is om het zand te mengen met een speciale formule (matrixvermenigvuldiging) zo snel mogelijk. Dit artikel is een gedetailleerd logboek van één onderzoeker, Lucas, die probeert die robotarm zo snel mogelijk te laten bewegen op een specifiek type computerchip genaamd de AMD Zen 3.

Het Grote Doel: Hoe Snel is Snel?

De robotarm heeft een theoretische topsnelheid van 134,4 GFLOPS (dat zijn 134,4 miljard rekenoperaties per seconde). Denk aan dit als de snelheidslimiet op een snelweg. Lucas wilde zien hoe dicht hij bij die snelheidslimiet kon komen zonder een compleet nieuwe auto te bous, simpelweg door de motor af te stellen.

Na het testen van 28 verschillende rijstrategieën, vond hij een "kampioensopstelling" (genaamd MX24) die 85,30 GFLOPS haalde. Dat is ongeveer 63,5% van de maximale snelheid. Het is geen perfecte 100%, maar het is een enorme sprong vanaf de startlijn, die een trage, onhandige methode draaide van slechts 1,51 GFLOPS. Sterker nog, zijn beste methode was 57 keer sneller dan de basis, niet-geoptimaliseerde versie.

De Winnende Strategie: De "4-Rij, Ketting-4" Dans

Om deze snelheid te bereiken, moest Lucas uitzoeken hoe hij het zand en de bewegingen van de robot moest organiseren. Hier zijn de belangrijkste zetten die hij ontdekte:

1. De "On-the-Fly" Paktechniek
Stel je voor dat het zand is opgeslagen in een rooster waarbij je diagonaal moet lopen om de volgende korrel te pakken. Dat is traag en vermoeiend. Lucas ontdekte dat het kopiëren van een klein stukje zand in een nette, rechte lijn vlak voordat de robot het nodig heeft (genaamd on-the-fly packing) de magische zet was. Het is alsof een helper vooruit rent en de stenen in een perfecte rij stapelt, zodat de robot ze er één na de andere kan pakken zonder te struikelen. Dit versloeg de oude methode van het gewoon pakken zoals ze lagen, en het was zelfs beter dan het hele magazijn vooraf te herschikken.

2. Het Stapelen van "4 Rijen"
De robot heeft een beperkt aantal handen (registers) om zand in vast te houden terwijl hij werkt. Lucas probeerde 2 rijen zand vast te houden, toen 4, toen 8.

2 Rijen: Te weinig. De robot moest te vaak stoppen om nieuw zand te halen.
8 Rijen: Te veel! De handen van de robot waren zo vol dat hij zand op de grond liet vallen (geheugen) en het constant weer moest oprapen. Dit was een ramp.
4 Rijen: Het ideale punt. Hoewel de robot wat zand op de grond moest laten vallen en weer moest oppakken (een proces dat "spilling" wordt genoemd), was de extra arbeid het waard omdat hij meer zand tegelijk kon verwerken. Deze enkele verandering maakte de robot 59% sneller dan de 2-rijen methode.

3. Het "Ketting-4" Ritme
De robotarm doet er 4 seconden (cycli) over om een enkele rekenstap te voltooien voordat hij de volgende stap kan starten op hetzelfde stukje zand. Als de robot één stap zou doen en dan zou wachten, zou hij 3 seconden niets doen.
Lucas ontdekte dat als de robot 4 verschillende zandhopen in zijn handen hield en in een lus werkte (Ketting-4), hij de arm constant in beweging kon houden. Terwijl één hoop zand "gaar was", werkte hij aan de andere hopen. Dit kwam perfect overeen met de 4-seconden "gaar-tijd" van de robot, waardoor de motor op volle snelheid bleef brommen.

Wat Niet Werkte (De "Niet Doen" Lijst)

Soms is wat je denkt dat zou moeten werken, in werkelijkheid slechter. Lucas testte een aantal populaire ideeën en ontdekte dat ze vreselijk waren voor deze specifieke robot:

De "Pre-fetch" Fout: Mensen vertellen robots vaak om "vooruit te kijken" en de volgende zandkorrel alvast te pakken voordat ze die nodig hebben. Lucas probeerde dit, maar de ingebouwde ogen van de robot waren al zo goed in het herkennen van het patroon, dat de extra "vooruitkijk"-opdrachten in de weg zaten. Dit vertraagde de robot met ongeveer 8%.
De "Non-Temporal" Dump: Er is een truc waarbij je de robot vertelt het zand direct op de grond te dumpen zonder het eerst in een bak te leggen. Dit werkt geweldig als je alleen maar afval dumpt. Maar hier moet de robot het zand juist mengen, wat betekent dat hij het weer moet oppakken. Het direct dumpen zorgde ervoor dat de robot over zijn eigen voeten struikelde, waardoor de snelheid instortte naar een magere 1,24 GFLOPS.
De "8-Rij" Overbelasting: Zoals eerder vermeld, zorgde het proberen vast te houden van 8 rijen zand ervoor dat de robot zoveel zand liet vallen dat hij meer tijd besteedde aan het oprapen ervan dan aan het verplaatsen.

Hoe Zeker Zijn We?

Het artikel is zeer zelfverzekerd over deze cijfers omdat ze werden gemeten, niet alleen geschat. Lucas draaide de code 15 keer voor elke strategie, gooide de snelste en de langzaamste runs eruit (om vreemde computerglitches te vermijden) en berekende het gemiddelde van de rest. Hij controleerde ook de wiskunde tegenover een simpele, trage versie om er zeker van te zijn dat de snelle versie niet had valsgespeeld.

Hij bouwde zelfs een wiskundig "pre-filter" model — een soort kristallen bol — om te voorspellen hoe snel een strategie zou zijn voordat hij deze daadwerkelijk uitvoerde. Deze kristallen bol was behoorlijk goed en kwam voor de meeste strategieën binnen een marge van 11,3% van de werkelijke snelheid. Het model was wat conservatiever; het voorspelde dat de beste strategie 78,1 GFLOPS zou halen, terwijl deze in de praktijk 85,30 GFLOPS haalde.

De Conclusie

Dit artikel bewijst dat je geen tovenaar hoeft te zijn die code in "assembly language" (de natuurlijke taal van de robot) schrijft om geweldige snelheden te bereiken. Door standaard tools (C++ intrinsics) te gebruiken en de "danspassen" (blocking, chaining en packing) zorgvuldig af te stemmen, kun je je computer laten draaien op 63,5% van zijn theoretische maximumsnelheid.

De belangrijkste les? Raad niet. Wat werkt voor de ene soort robot (of computerchip), kan de andere kapotmaken. Lucas testte 28 verschillende combinaties om te vinden wat werkte, wat aantoont dat de "voor de hand liggende" trucs (zoals vooruitkijken of direct dumpen) soms juist de verkeerde zetten zijn.

Titel: 85,30 GFLOPS Single-Core FP32 Matrixvermenigvuldiging op AMD Zen 3: Een Systematische Studie naar Cache Blocking, Register Blocking, FMA Chaining en On-the-Fly Packing

Probleemstelling
Matrixvermenigvuldiging (GEMM) is een fundamentele operatie in wetenschappelijk rekenen en machine learning, maar het bereiken van piekprestaties op moderne processors vereist het navigeren door een complex landschap van geheugenhiërarchieën, registerfiles en pipeline-beperkingen. Hoewel bibliotheken zoals BLIS en OpenBLAS hoog geoptimaliseerde kernels bieden, is er behoefte aan een systematisch begrip van hoe specifieke optimalisatietechnieken interageren met hedendaagse microarchitecturen, in het bijzonder AMD Zen 3. Dit artikel behandelt de uitdaging om de single-core floating-point doorvoer voor de GEMM-kernel ( $C = \alpha AB + \beta C$ ) op de AMD Ryzen 5 5500 te maximaliseren, zonder terug te vallen op handgeschreven assembly of externe propriëtaire bibliotheken.

Methodologie
De studie maakt gebruik van een systematische verkenning van een designruimte bestaande uit 28 verschillende optimalisatiemodellen (MX00–MX28) gericht op de AMD Zen 3 microarchitectuur. De methodologie omvat:

Doelarchitectuuranalyse: Gedetailleerde examinatie van de Zen 3-core, specifal de 4-cyclus FMA-latentie, duale 256-bit FMA-poorten, 16 architecturale YMM-registers en de drie-lagen cachehiërarchie (32 KB L1, 512 KB L2, 16 MB L3).
Optimalisatiedimensies: De auteurs variëren combinatorisch de belangrijkste technieken:
- Cache Blocking: Drie-lagen tiling (L1, L2, L3) met variërende blokgroottes ( $B_I, B_J, B_K$ ).
- Register Blocking: Partitionering van de accumulator-matrix $C$ in 2-rijen, 4-rijen en 8-rijen schema's om gebruik te maken van de 16 beschikbare YMM-registers.
- FMA Chaining: Implementatie van chain-lengtes van 1 tot 6 om de 4-cyclus FMA-latentie te maskeren.
- Packing Strategieën: Vergelijking van geen packing, expliciete matrixtranspositie ( $B^T$ ) en on-the-fly $B$ -packing.
- Auxiliaire Technieken: Geheugenuitlijning, software prefetching en non-temporal stores.
Experimentele Opstelling: Experimenten werden uitgevoerd op een enkele core van een AMD Ryzen 5 5500 draaiend op 4,2 GHz. De code werd geschreven in C++ met intrinsics en gecompileerd met GCC 12.2 op -O3. Prestaties werden gemeten voor vierkante matrices met dimensie $N=2048$ met behulp van FP32 datatypen.
Voorspellend Model: Een wiskundig pre-filter model werd ontwikkeld om prestaties a priori te schatten op basis van pipeline-penalties, registerdruk en cache miss-rates, gekalibreerd tegen de 28 experimentele modellen.

Belangrijkste Bijdragen en Resultaten
Het artikel presenteert een kampioensconfiguratie, MX24, die 85,30 GFLOPS bereikt, wat 63,5% vertegenwoordigt van de theoretische single-core piek van 134,4 GFLOPS. Dit resultaat is ongeveer 57× sneller dan een naïeve triple-loop implementatie.

Optimale Configuratie: Het winnende model maakt gebruik van een 4-rijen register block, chain4 FMA chaining (overeenkomend met de 4-cyclus latentie), on-the-fly B-packing, en een diepe tile-grootte van $B_K = 256$ (passend binnen de L2-cache).
Contraintuïtieve Bevindingen:
- Register Spilling: Ondanks dat er 16 register spills vereist zijn (32 logische registers nodig versus 16 fysieke), presteerde het 4-rijen schema 59% beter dan het spill-vrije 2-rijen schema. De compiler plande de spill-operaties efficiënt tijdens pipeline bubbles, waarbij de verhoogde hergebruik van $A$ -elementen de overhead van het geheugen compenseerde.
- Software Prefetching: Tegen de algemene intuïtie in, degradeerde software prefetching de prestaties met ongeveer 8%, omdat de Zen 3 hardware prefetcher al zeer effectief was voor de streaming access patronen van GEMM.
- Non-Temporal Stores: Het gebruik van non-temporal stores voor de $C$ matrix veroorzaakte een catastrofale prestatie-instorting naar 1,24 GFLOPS, omdat GEMM een read-modify-write operatie is, en het omzeilen van de cache de data invalideerde die nodig was voor opeenvolgende loads.
- Packing Efficiëntie: On-the-fly packing presteerde beter dan volledige matrixtranspositie door cache-vervuiling tijdens de setup-fase te vermijden, terwijl het een aaneengesloten geheugentoegang bood die vergelijkbaar is met transpositie.
Voorspellend Model: Het wiskundige pre-filter model bereikte een Mean Absolute Percentage Error (MAPE) van 11,3% over de designruimte, waarbij het succesvol hoogpresterende configuraties identificeerde met een conservatieve bias.

Significantie en Claims
De auteurs beweren dat dit werk een reproduceerbare referentie biedt voor single-core GEMM optimalisatie op hedendaagse x86-64 microarchitecturen. De primaire significantie ligt in het feit dat het aantoont dat zorgvuldig handmatig getunede gevectoriseerde code met C++ intrinsics binnen een factor 2 van de roofline ceiling kan komen zonder externe bibliotheken of handgeschreven assembly.

Het artikel benadrukt dat systematische, combinatorische optimalisatie betere resultaten oplevert dan het vertrouwen op algemene heuristieken, zoals blijkt uit het falen van technieken zoals software prefetching en non-temporal stores in deze specifieke context. De 85,30 GFLOPS resultaat is competitief met volwassen, vendor-geoptimaliseerde bibliotheken (zoals AMD AOCL en Intel MKL) op vergelijkbare hardware, wat de effectiviteit van de beschreven optimalisatie-template (4-rijen, chain4, on-the-fly packing) voor x86-64 architecturen met AVX2/FMA ondersteuning valideert. Het werk benadrukt ook het cruciale belang van compilerkwaliteit, waarbij wordt opgemerkt dat GCC 12.2 aanzienlijk betere code produceerde dan Microsoft Visual C++ voor deze specifieke intrinsics.

Het Grote Doel: Hoe Snel is Snel?

De Winnende Strategie: De "4-Rij, Ketting-4" Dans

Wat Niet Werkte (De "Niet Doen" Lijst)

Hoe Zeker Zijn We?

De Conclusie

Meer zoals dit