Fremtidens HPC-compilere: Sådan løser NektarIR det heterogene hardware-mareridt

Hvis du har fulgt med i high-performance computing det sidste stykke tid, har du sikkert lagt mærke til en bekymrende udvikling: hardware-landskabet er blevet fragmenteret rod. Moderne supercomputere og selv kraftige workstation-maskiner har i dag heterogene arkitekturer – en blanding af traditionelle CPU'er med GPU'er, muligvis nogle FPGA'er og specialiserede acceleratorer fra forskellige leverandører. Hver type hardware taler sit eget sprog, når det gælder optimering, og at få din kode til at køre effektivt på tværs af det hele kan føles som at samle katte.

Det er problemet NektarIR tager fat på, og ærligt talt er det forfriskende at se nogen tage en systematisk tilgang frem for bare at kaste mere hånd-tuned assembly efter problemet.

Revolutionen i compilere-stakken

Traditionelle compilere som GCC eller LLVM arbejder på et ret højt niveau – de tager kildekode og producerer optimeret maskinkode. Men når du arbejder med domænespecifikke operationer, hvad enten det er finite element-metoder eller machine learning-kerner, er der et kæmpe semantisk hul mellem det, din domæneekspert tænker på (differentialligninger, elementmatricer), og det hardware'en faktisk forstår (registre, hukommelseshierarkier, SIMD-vejløb).

MLIR, udviklet hos Google og nu en hjørnesten i LLVM, kom med en genial idé: i stedet for at have én monolitisk repræsentation, hvorfor så ikke understøtte flere niveauer af intermediate representation, hver tilpasset forskellige abstraktionsniveauer? Man kan definere custom "dialects" der fanger domæne-begreber direkte, og så progressive lowering dem mod hardware-specifikke instruktioner mens man anvender optimeringer på hvert stadie.

NektarIR anvender denne filosofi på spectral/hp element-metoder til computational fluid dynamics. Hvis du aldrig har hørt om spectral element-metoder, så tænk på dem som en sofistikeret numerisk teknik til at løse partielle differentialligninger – de er særligt populære inden for aerospace og vejrudsigt-modellering fordi de kan opnå høj præcision med forholdsvist grove grids.

Hvorfor Finite Element-operationer er anderledes

Her er det der gør finite element-metoder interessante fra et compiler-perspektiv: ydelsen drives af et overraskende lille sæt af almindelige operatorer, der sammensættes på forskellige måder for at skabe komplekse differentialligninger. Vi taler om operationer som basisfunktions-evaluering, matrix-vektor produkter og kvadratur-beregninger – operationer der ser forfærdeligt simple ud men som er utroligt følsomme over for memory access patterns og cache-udnyttelse.

I traditionelle tilgange ville udviklere skrive optimerede kerner til hver arkitektur, og så vedligeholde parallelle versioner til CPU'er og GPU'er. Resultatet er et vedligeholdelses-mareridt hvor en enkelt algoritmisk ændring kan kræve opdatering af snesevis af leverandør-specifikke implementeringer.

NektarIR undgår dette ved at skabe sin egen MLIR dialect der direkte repræsenterer disse finite element-operatorer. Tænk på det som et ordforråd specifikt designet til at tale om spectral element-beregninger. Når man først har dette domæne-specifikke sprog integreret i sin compiler-infrastruktur, kan man skrive optimeringer der forstår semantikken i det man laver – ikke bare de rå operationer.

Magien i progressive lowering

Den egentlige styrke kommer fra lowering-pipelinen. I NektarIR starter man med en high-level repræsentation der ligner meget det en matematiker ville bruge til at beskrive en finite element-operator. Efterhånden som repræsentationen bevæger sig gennem successive stadier, bliver den mere og mere konkret:

1. Den domæne-specifikke dialect fanger den matematiske struktur
2. Bufferization håndterer hukommelsesallokering og data-bevægelse
3. Hardware-specifik lowering tilpasser operationerne til CPU eller GPU executionsmodeller
4. Endelig code generation producerer optimerede maskiningstruktioner

På hvert niveau kan optimeringer anvendes der er specifikke for den abstraktion. Dette er langt mere effektivt end at prøve at reverse-engineere high-level intent fra low-level operationer – noget traditionelle compilere kæmper med på domæne-specifik kode.

Real-world performance

NektarIR-teamet demonstrerede deres tilgang ved at sammenligne med det etablerede Nektar++ spectral/hp element-framework. Resultaterne viser at deres just-in-time compilation-tilgang opnår konkurrencedygtig eller bedre performance på både CPU og GPU arkitekturer, hvilket er imponerende taget i betragtning af at de arbejder fra en enkelt, samlet kodebase frem for hånd-optimerede implementeringer til hver platform.

Dette er særligt betydningsfuldt fordi CFD-simuleringer ofte kører i dage eller uger på supercomputere. Selv små procentsatser-forbedringer i kerne-performance omsættes til betydelige tids- og energibesparelser i stor skala.

Hvad dette betyder for udviklere

Du tænker måske: "Dette er interessant, men jeg skriver ikke CFD-solvers." Fair nok – men den underliggende teknik har brede implikationer. Mønstret med at definere domæne-specifikke dialects, progressive lowering gennem abstraktionsniveauer og anvende målrettede optimeringer på hvert stadie er anvendeligt langt ud over finite element-metoder.

Vi ser allerede MLIR brugt til TensorFlow's ML-workloads, IREE til embedded AI inference og diverse forskningsprojekter inden for quantum computing og signalbehandling. Efterhånden som specialiseret hardware fortsætter med at brede sig, bliver evnen til at skrive kode én gang og compilere den effektivt til forskellige targets stadig mere værdifuld.

NektarIR-projektet demonstrerer at vi er på vej ind i en æra hvor compilere virkelig kan co-designes med deres target-domæner. I stedet for at tvinge domæneeksperter til at blive compiler-ingeniører eller forvente at compiler-forfattere skal forstå nuancerne i spectral element-metoder, kan vi bygge værktøjer der elegant bygger bro over denne kløft.

For HPC-miljøet repræsenterer dette en vej frem fra den nuværende situation hvor porting af applikationer til nye arkitekturer kræver heroisk ingeniørarbejde. For udviklere generelt er det et glimt af hvordan compilation-teknologi kan udvikle sig til at håndtere den stadig mere heterogene fremtid for computing.

Koden er tilgængelig for dem der vil eksperimentere, og tilgangen er generaliserbar nok til at lignende teknikker kan anvendes på andre compute-intense domæner. Uanset om du simulerer klimamodeller eller bare prøver at klemme mere performance ud af din GPU-accelererede applikation, er idéerne bag NektarIR værd at forstå.

Har du oplevet udfordringer med heterogen hardware i dine projekter? Hvad er din holdning til domæne-specifikke compilation-tilgange? Skriv en kommentar – vi vil meget gerne høre om dine erfaringer.