A HPC fordítók jövője: Így oldja meg a NektarIR a heterogén hardverek rémálmát

Ha az utóbbi időben belenéztél a nagy teljesítményű számítástechnikába (HPC), valószínűleg te is észrevetted, hogy a hardverek világa igencsak szétaprózódott. A modern szuperszámítógépek, de még a combos munkaállomások is vegyes architektúrákat használnak – CPU-k, GPU-k, esetleg FPGA-k és különböző gyártóktól származó specializált gyorsítók kombinációját. Minden egyes hardverelem más-más nyelven "beszél", ha optimalizálásról van szó, és a kódunkat hatékonyan átvinni mindegyikre olyan, mintha macskákat terelnénk.

Ez az a probléma, amivel a NektarIR szembenéz, és őszintén szólva, felüdülés látni, hogy valaki rendszerszinten közelíti meg, ahelyett hogy egyszerűen több kézzel optimalizált assembly kóddal dobálózna.

A fordítói stack forradalma

A hagyományos fordítók, mint a GCC vagy az LLVM, viszonylag magas szinten működnek – forráskódból optimalizált gépi kódot állítanak elő. De amikor domain-specifikus műveletekkel dolgozol, legyen szó végeselemes módszerekről vagy gépi tanulási kernelekről, hatalmas szemantikai szakadék tátong közötte, amit a szakértő gondol (differenciáloperátorok, elem-mátrixok) és amit a hardver valójában ért (regiszterek, memóriahierarchiák, SIMD sávok).

Az MLIR, amit a Google fejlesztett ki és mára az LLVM alapköve lett, egy zseniális ötlettel állt elő: miért ne lehetne több szintű köztes reprezentáció, amelyek mindegyike más absztrakciós szinthez van finomhangolva? Definiálhatsz egyedi "dialektusokat", amelyek közvetlenül ragadják meg a domain fogalmait, majd fokozatosan lejjebb "fordíthatod" őket a hardware-specifikus utasításokig, miközben minden szinten alkalmazol optimalizálásokat.

A NektarIR ezt a filozófiát alkalmazza a spektrális/hp elem módszerekre a számítási fluidodinamikában. Ha még nem hallottál a spektrális elem módszerekről, gondolj rá úgy, mint egy kifinomult numerikus technikára, amelyet parciális differenciálegyenletek megoldására használnak – különösen népszerűek a repülőgépiparban és időjárás-modellezésben, mert viszonylag durva rácsokkal is nagy pontosságot lehet elérni.

Miért mások a végeselemes műveletek

Íme, ami a végeselemes módszereket érdekessé teszi a fordítás szempontjából: a teljesítményt meglepően kevés gyakori operátor hajtja, amelyeket aztán különböző módokon állítanak össze komplex differenciáloperátorokká. Olyan műveletekről beszélünk, mint a bázisfüggvények kiértékelése, mátrix-vektor szorzatok és kvadratúra számítások – műveletek, amelyek álcázottan egyszerűnek tűnnek, de rendkívül érzékenyek a memória-hozzáférési mintákra és a cache kihasználtságra.

A hagyományos megközelítésekben a fejlesztők minden architektúrára külön optimalizált kernelt írtak, majd karbantartották a párhuzamos verziókat CPU-kra és GPU-kra. Az eredmény egy karbantartási rémálom, ahol egyetlen algoritmikus változtatás akár tucatnyi gyártó-specifikus implementáció frissítését igényelheti.

A NektarIR ezt megkerüli azzal, hogy saját MLIR dialektust hoz létre, amely közvetlenül reprezentálja ezeket a végeselemes operátorokat. Gondolj rá úgy, mint egy speciális szókészletre, amelyet kifejezetten a spektrális elem számításokról való beszédhez terveztek. Miután ez a domain-specifikus nyelv beépül a fordítói infrastruktúrába, olyan optimalizálásokat írhatsz, amelyek értik, mit csinálsz – nem csak a nyers műveleteket.

A progresszív leszállítás varázsa

A valódi erő a lowering (leszállítási) csővezetékből származik. A NektarIR-ben magas szintű reprezentációval kezded, amely nagyon közel áll ahhoz, ahogy egy matematikus leírna egy végeselemes operátort. Ahogy a reprezentáció átmegy egymást követő szinteken, egyre konkrétebbé válik:

1. A domain-specifikus dialektus megragadja a matematikai struktúrát
2. A bufferizáció kezeli a memóriafoglalást és az adathalmaz mozgatást
3. A hardware-specifikus lowering az operátorokat CPU vagy GPU végrehajtási modellekhez igazítja
4. A végső kódgenerálás optimalizált gépi utasításokat állít elő

Minden szinten specifikus optimalizálások alkalmazhatók. Ez sokkal hatékonyabb, mint megpróbálni a magas szintű szándékot rekonstruálni az alacsony szintű műveletekből – amivel a hagyományos fordítók küzdenek a domain-specifikus kódokon.

Valós teljesítmény

A NektarIR csapat a bevált Nektar++ spektrális/hp elem keretrendszerrel hasonlította össze a megközelítésüket. Az eredmények azt mutatják, hogy a just-in-time fordítási megközelítésük versenyképes vagy jobb teljesítményt ér el mind CPU, mind GPU architektúrákon – ami lenyűgöző, figyelembe véve, hogy egyetlen egységes kódbázisból dolgoznak, nem pedig kézzel optimalizált implementációkból minden egyes platformhoz.

Ez azért különösen jelentős, mert a CFD szimulációk gyakran napokig vagy hetekig futnak szuperszámítógépeken. Még a kernel teljesítményének kis százalékos javulása is jelentős idő- és energia-megtakarítást jelent méretezéskor.

Mit jelent ez a fejlesztőknek

Gondolhatod azt, hogy "Érdekes, de én nem CFD megoldókat írok." Ez fair – de az alapul szolgáló technika széles körű következményekkel jár. Az a minta, hogy domain-specifikus dialektusokat definiálunk, fokozatosan átalakítjuk őket az absztrakciós szinteken, és minden szinten célzott optimalizálásokat alkalmazunk, messze túlmutat a végeselemes módszereken.

Már látjuk az MLIR használatát a TensorFlow ML munkaterheléseihez, az IREE beágyazott AI következtetéséhez, és különböző kutatási projektekben kvantumszámításhoz és jelfeldolgozáshoz. Ahogy a specializált hardware egyre terjed, egyre értékesebbé válik az a képesség, hogy egyszer írsz kódot, és hatékonyan lefordítod különböző célplatformokra.

A NektarIR projekt bizonyítja, hogy belépünk egy olyan korszakba, ahol a fordítók valóban együtt tervezhetők a célzott domainekkel. Ahelyett, hogy a domain szakértőket kéne compiler mérnökökké képezni, vagy a compiler íróknak kellene érteniük a spektrális elem módszerek árnyalatait, építhetünk olyan eszközöket, amelyek elegánsan hidalják át ezt a szakadékot.

A HPC közösség számára ez egy járható utat jelent a jelenlegi helyzetből, ahol az alkalmazások új architektúrákra portolása hősies mérnöki erőfeszítéseket igényel. A fejlesztők általában véve pedig egy betekintést kapnak abba, hogyan fejlődhet a fordítási technológia a számítás jövőjének egyre heterogénebb világában.

A kód elérhető azoknak, akik szeretnének kísérletezni, és a megközelítés elég általános ahhoz, hogy hasonló technikák alkalmazhatók legyenek más számításigényes domainekben is. Legyen szó klímamodellek szimulálásáról vagy egyszerűen arról, hogy több teljesítményt préselj ki a GPU-gyorsított alkalmazásodból, a NektarIR mögötti ötletek megértése megéri az energiát.

Találkoztál már a heterogén hardware kihívásaival a projektjeidben? Mi a véleményed a domain-specifikus fordítási megközelítésekről? Írj kommentet – kíváncsiak vagyunk a tapasztalataidra.