🤖 machine learning

LP-GEMM: Integrating Layout Propagation into GEMM Operations

Dit paper introduceert LP-GEMM, een methode die herhaaldelijke inpak- en uitpakbewerkingen elimineert door lay-outpropagatie tussen opeenvolgende GEMM-operaties, wat leidt tot aanzienlijke snelheidswinsten op zowel x86- als RISC-V-architecturen.

Oorspronkelijke auteurs: César Guedes Carneiro, Lucas Alvarenga, Guido Araujo, Sandro Rigo

Gepubliceerd 2026-04-07

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: César Guedes Carneiro, Lucas Alvarenga, Guido Araujo, Sandro Rigo

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://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 hoeveelheid data moet verwerken, zoals het lezen van een heel boek of het analyseren van duizenden foto's. In de wereld van computers, en vooral bij kunstmatige intelligentie (AI), gebeurt dit vaak door enorme "rechthoekige blokken" met getallen te vermenigvuldigen. Dit noemen experts GEMM (General Matrix Multiplication), maar voor ons is het gewoon het rekenen met grote tabellen.

Het probleem is dat de computersoftware die dit doet (zoals OpenBLAS) vaak heel inefficiënt werkt. Het is alsof je een kok bent die elke keer dat hij een gerecht moet bereiden, eerst alle ingrediënten uit de verpakking haalt, ze op een bord legt, ze bereidt, en daarna elke keer opnieuw alles terug in de verpakking stopt, alleen om het direct daarna weer uit te pakken voor het volgende gerecht.

Dit is precies wat er gebeurt in de huidige AI-modellen:

De computer pakt de data in een handige vorm (verpakken).
Hij doet de berekening.
Hij stopt de data weer terug in de "oude" vorm (uitpakken) zodat de volgende stap het kan lezen.
De volgende stap pakt het opnieuw in, berekent het, en stopt het weer terug.

Dit "in- en uitpakken" kost enorm veel tijd en energie, terwijl de computer eigenlijk gewoon door zou moeten rekenen.

De Oplossing: LP-GEMM (De "Doorlopende Band")

De auteurs van dit paper hebben een slimme oplossing bedacht die ze LP-GEMM noemen. Ze noemen het "Layout Propagation", wat je kunt vertalen als "het doorgeven van de verpakking".

In plaats van elke keer te stoppen en alles te verpakken en uit te pakken, laten ze de data in de handige vorm door de hele keten van berekeningen lopen.

De Analogie van de Fabriek:
Stel je een fabriek voor waar auto's worden gebouwd:

De oude manier (OpenBLAS): Elke werknemer (stap in de berekening) neemt de auto in stukken mee, bouwt een wiel, en stopt de auto daarna weer in dozen. De volgende werknemer moet de dozen openmaken, het wiel eruit halen, een deur bouwen, en de auto weer in dozen stoppen. Dit kost veel tijd met dozen en karton.
De nieuwe manier (LP-GEMM): De eerste werknemer pakt de auto in een speciale, handige karretje. Hij bouwt het wiel en schuift het karretje direct door naar de volgende werknemer. Die werknemer bouwt de deur zonder de auto uit het karretje te halen. De auto blijft in het karretje zitten tot hij helemaal klaar is. Pas aan het einde, bij de laatste werknemer, wordt de auto uit het karretje gehaald en op de vrachtwagen geladen.

Hoe werkt dit in de praktijk?

De auteurs hebben de software opgesplitst in drie soorten "werknemers":

De Starter: Pakt de data in de handige vorm in en begint de berekening.
De Tussenstap: Krijgt de data al in de handige vorm, doet zijn werk, en geeft het zo door aan de volgende. Geen verpakking nodig!
De Afwerker: Krijgt de data in de handige vorm, doet het laatste stuk werk, en pakt het pas aan het einde uit zodat het resultaat weer normaal is.

Wat levert dit op?

Ze hebben dit getest op twee soorten computers:

Intel-computers (x86): Hier was het ongeveer 2,25 keer sneller dan de standaard software.
RISC-V-computers (een nieuwere, open-source architectuur): Hier was het zelfs tot 5 keer sneller!

Dit is een enorme winst. Het betekent dat AI-modellen (zoals de beroemde Llama-3.2, die ze in hun onderzoek hebben gebruikt) veel sneller kunnen denken en minder stroom verbruiken.

Waarom is dit belangrijk voor jou?

Je merkt dit misschien niet direct, maar dit soort verbeteringen zorgen ervoor dat:

Chatbots sneller antwoorden.
Je telefoon minder snel leegloopt als je AI-functies gebruikt.
Wetenschappers en bedrijven goedkopere en snellere computers nodig hebben om complexe problemen op te lossen.

Kortom: LP-GEMM is een slimme manier om te voorkomen dat computers tijd verspillen aan het "in- en uitpakken" van data. Het zorgt ervoor dat de computer zich focust op wat hij echt goed kan: rekenen.

Titel en Context

Titel: LP-GEMM: Integrating Layout Propagation into GEMM Operations
Auteurs: C´esar Guedes Carneiro e.a. (Universiteit van Campinas, Brazilië)
Doel: Het optimaliseren van sequentiële General Matrix Multiplication (GEMM) operaties in wetenschappelijk rekenen en Machine Learning (ML) door redundantie in data-packing te elimineren.

1. Het Probleem

In moderne ML-werklasten (zoals Multi-Layer Perceptrons en Transformers) worden vaak lange reeksen afhankelijke GEMM-operaties uitgevoerd. Bestaande geoptimaliseerde BLAS-bibliotheken (zoals OpenBLAS, Intel MKL) zijn ontworpen om individuele GEMM-aanroepen te optimaliseren, maar ze opereren binnen de beperkingen van de standaard BLAS-API.

Redundante Packing/Unpacking: De BLAS-API vereist dat elke GEMM-aanroep de invoermatrices in een specifieke, canonieke opslagindeling (layout) verpakt (packing) en het resultaat weer in die standaardindeling terugzet (unpacking) na de berekening.
Inefficiëntie: Wanneer GEMM-operaties achter elkaar worden uitgevoerd (waarbij de output van de ene de input is van de volgende), wordt de output van de eerste operatie eerst uitgepakt en vervolgens direct weer ingepakt voor de volgende operatie. Dit veroorzaakt aanzienlijke, onnodige overhead in geheugentoegang en CPU-cycli, wat de totale doorvoersnelheid beperkt.

2. Methodologie: LP-GEMM

De auteurs introduceren LP-GEMM (Layout Propagation GEMM), een decompositie van de OpenBLAS GEMM-kernel die de data-indeling tussen opeenvolgende operaties behoudt in plaats van deze te resetten.

Kernconcept:
In plaats van elke GEMM als een geïsoleerde eenheid te behandelen, worden drie gespecialiseerde kernels ontwikkeld die samenwerken om de "gepakte" indeling (packing layout) door te geven:

Initial GEMM (ini-GEMM): Voert de initiële packing uit en start de propagatie van de layout. De output wordt opgeslagen in een geoptimaliseerde, niet-standaard indeling die direct bruikbaar is voor de volgende stap.
Intermediate GEMM (mid-GEMM): Ontvangt data die al is ingepakt door de vorige stap. Deze kernel slaat de packing over (geen nieuwe packing nodig) en behoudt de layout voor de volgende operatie. Dit is de kern van de versnelling.
Ending GEMM (end-GEMM): Voert de laatste berekening uit en pakt de data opnieuw uit naar de standaard BLAS-indeling, zodat de gebruiker een correct resultaat ontvangt.

Technische Implementatie:

Micro-kernels: Er worden twee soorten micro-kernels gebruikt: een Propagate-Layout µkernel (houdt de layout vast) en een Default µkernel (herstelt de standaard layout).
Layout-continuïteit: De methode zorgt ervoor dat de opslagindeling van de output van operatie $N$ exact overeenkomt met de vereiste ingangsindeling van operatie $N+1$ . Dit elimineert de noodzaak voor tussenliggende herschikkingen.
Aanpassing voor ML: Voor complexe lagen zoals de Attention-layer in Transformers (bijv. LLaMA), worden tussenliggende operaties (zoals Softmax en RoPE) aangepast om te werken met de gepropageerde layout, vaak door SIMD-instructies te gebruiken voor rij-interleaving.

3. Belangrijkste Bijdragen

Decompositie van de GEMM-kernel: Het opsplitsen van de GEMM-operatie in ini-, mid- en end-GEMM kernels om layout-propagatie mogelijk te maken.
Standalone Implementatie: Een volledige C++ implementatie van de inferentie-paath van Llama-3.2 die uitsluitend BLAS-niveau GEMM-aanroepen gebruikt, maar met LP-GEMM-optimalisaties.
Implementatie van ML-operaties: Het aanpassen van veelvoorkomende operaties (Softmax, RoPE, RMSNorm) om te werken met de gepropageerde layout op AVX-512 hardware.
Cross-architectuur Onderzoek: Evaluatie op zowel Intel x86 (AVX-512) als RISC-V (RVV 1.0) platformen.

4. Resultaten

De prestaties zijn getest op een Intel Xeon Gold 6252 (x86) en een SpacemiT X60 (RISC-V).

Vergelijking met OpenBLAS:
- Voor sequentiële GEMM's (zoals in Attention-lagen) wordt een gemiddelde snelheidswinst van 2,25x behaald op Intel x86 ten opzichte van OpenBLAS.
- Op RISC-V zijn de winsten nog groter, met snelheidsverhogingen tot 5x voor Attention-achtige werklasten.
Vergelijking met Vendor Libraries:
- Op x86 presteert LP-GEMM concurrerend met geoptimaliseerde vendor-bibliotheken zoals Intel MKL, hoewel MKL nog steeds iets sneller is voor geïsoleerde GEMM's door diepere micro-kernel optimalisaties.
- De winst van LP-GEMM komt voornamelijk uit het elimineren van packing-overhead, terwijl MKL en BLIS vooral winnen door betere micro-kernel tuning.
Gedrag bij Grootte:
- Op x86 nemen de snelheidswinsten af bij zeer grote matrices, omdat de kosten van packing relatief kleiner worden ten opzichte van de berekeningstijd ( $O(n^2)$ vs $O(n^3)$ ).
- Op RISC-V neemt de snelheidswinst lineair toe met de matrixgrootte, omdat de baseline OpenBLAS-implementatie op deze architectuur inefficiënt is bij het uitvoeren van de unpacking-stap (out-of-order geheugentoegang).

5. Betekenis en Conclusie

Het paper toont aan dat het optimaliseren van individuele kernels niet voldoende is voor moderne ML-werklasten. Door de data-layout continuïteit tussen operaties te benutten, kunnen significante prestatiewinsten worden behaald zonder de complexiteit van low-level micro-architecturale tuning te vergroten.

Praktische Toepasbaarheid: De methode is bewezen in een realistische scenario (LLaMA-3.2 inferentie) en is niet beperkt tot micro-benchmarks.
Toekomstperspectief: LP-GEMM suggereert een verschuiving in de HPC-wereld van het optimaliseren van geïsoleerde kernel-aanroepen naar het optimaliseren van end-to-end werklasten. De techniek kan worden uitgebreid naar andere operaties (zoals convoluties) en andere architecturen.
Beperking: Het is geen "drop-in" vervanging voor de standaard BLAS-API omdat het specifieke parameters vereist voor gestructureerde geheugentoegang en de output-indeling afwijkt van de standaard totdat de end-GEMM wordt aangeroepen.

Kortom, LP-GEMM biedt een krachtige, architectuur-onafhankelijke aanpak om de inefficiëntie van redundant data-packen in sequentiële matrixvermenigvuldigingen op te lossen, wat essentieel is voor de efficiëntie van toekomstige AI-modellen op diverse hardware-platforms.