Kovácsolt és keresett, ami kiérdemli a bizonyítékát
A régi trükkprobléma
Minden komoly szoftverrendszerben van néhány kódrészlet, amely sokkal fontosabb, mint amit a mérete sugall. Egy ciklus, amely milliószor fut le. Egy bitművelet egy tömörítési útvonalban. Egy kis mátrixrutin. Egy moduláris aritmetikai mag. Az a fajta dolog, ami kódellenőrzéskor ártalmatlannak tűnik, majd csendben eldönti az energiaszámlát, a késleltetési keretet vagy a megvásárolandó gépek számát. Nagyon demokratikus a szoftver. Egy apró függvény tönkreteheti az értekezletet mindenki számára.
Történelmileg ezeket a magokat emberek fejlesztik. Egy vezető mérnök emlékszik egy trükkre egy tanulmányból. Valaki átkutat egy régi fórumbejegyzést. Egy benchmark-készletet írnak. Néhány jelöltet kipróbálnak. A leggyorsabb nyer, ha még mindig helyesnek tűnik. Ezután a szervezet befagyasztja, mert újra hozzányúlni olyan érzés, mintha villával piszkálnánk egy alvó transzformátort.
A Forge kutatás ennek a folyamatnak egy jobb változatára. Ez egy programszintézis-motor kis, kritikus implementációkhoz: adj neki tipizált specifikációt és tulajdonságokat, hadd keressen jelölt programokat, mérje és hasonlítsa össze a kompromisszumokat, ellenőrizze az egyenértékűséget, majd csökkentse a felfedezett implementációt a fontos célpontokra. A fontos szó nem a keresés. A fontos szó a még. Még mindig helyesnek kell lennie.
Ezért él a Forge a kutatásban. Nem egy nyilvános termékgomb, ahol valaki beírja, hogy gyorsabban, és csodát kap. Ez egy szintézis-munkaasztal partnerkísérletekhez, magfelfedezéshez és kutatáshoz arról, hogy meddig juthat az automatizált keresés, ha ellenőrzéshez kötik a benchmark-színház helyett.
A specifikáció a rajtvonal
Optimalizálás specifikáció nélkül csak szerencsejáték szebb változónévvel. Amint megjelenik egy okos jelölt, a csapatnak tudnia kell, mit kell megőriznie. Kezeli-e az összes bemenetet, vagy csak a benchmark barátságosait? Tiszteletben tartja-e a túlcsordulási viselkedést? Érvényes-e az algebrai azonosság a ténylegesen használt reprezentáció alatt? Megtartja-e ugyanazt a szemantikát, ha másik háttérrendszerre csökkentik?
A Forge tipizált kifejezésekkel és tulajdonságokkal kezd, mert a keresésnek határra van szüksége. A határ megmondja, mi számít egyenértékűnek. Enélkül a motor elképesztően gyorsat találhat azzal, hogy törli a munka felét. A számítógépek kiválóak a rosszindulatú megfelelésben, ha a szerződés homályos.
A keresési oldal szándékosan többes számú. Az enumeratív keresés akkor hasznos, ha a tér elég kicsi a lefedéshez. A CEGIS akkor hasznos, ha ellenpéldák vezérelhetik a finomítást. A genetikus programozás és az MCTS másképp fedez fel. Az ML-vezérelt keresés költségmodelleket tanulhat, és előnyben részesítheti az ígéretes régiókat. Egyik sem univerzálisan a legjobb. Ez nem gyengeség. Így viselkedik a keresés a való világban. Ha egy kalapács megoldana minden magot, a szerszámládák nagyon unalmasak lennének, és a hardvergyártók munkanélküliek lennének.
A kutatási kérdés az, hogyan kombináljuk ezeket a motorokat elég bizonyítási nyomással ahhoz, hogy az eredmény ne csak okos legyen. Egy szintetizált magnak túl kell élnie mind a boldog út benchmarkját, mind a boldogtalan út ellenőrzőjét. Különben a fejlesztés nem mérnöki munka. Ez egy trükk karbantartási költséggel.
Az ellenőrző a felnőtt a szobában
Forge azért használ ellenőrzési folyamatot, mert egyetlen ellenőrzés sem elegendő minden területhez. A gyors példák olcsók és hasznosak. A tulajdonságtesztek a hibák széles körét tárják fel, és a cáfoló példákat emberi szemmel is olvasható méretűre egyszerűsítik. Az olyan SMT-megoldók, mint a Z3 és a CVC5, bizonyítani tudják az egyenértékűséget, ahol a kódolás kezelhető. A kimerítő ellenőrzés kis tartományokban praktikus. Az E-gráf egyenlőség-telítettség újabb utat kínál az algebrai egyenértékűséghez.
A folyamat azért fontos, mert a kernelek bosszantó módokon hibáznak. Egy jelölt átmegy minden szokásos teszten, mégis hibás lehet egy élbéli esetben. Lehet helyes előjel nélküli bemenetekre, és hibás előjelesekre. Lehet helyes matematikai értelemben, és hibás, miután a választott reprezentáció túlcsordul. Lehet helyes a leszállítás előtt, és finoman hibás egy utasításkiválasztási döntés után. Az ellenőrző azért létezik, mert az optimizmus nem tesztelési stratégia. Ellenőriztük. Többször is. Ez továbbra is igaz.
Van egy gyakorlati ok is arra, hogy több bizonyítási utat tartsunk fenn. A formális módszerek erősek, de nem ingyenesek. Egyes kódolások időtúllépésbe futnak. Egyes tartományok túl nagyok a kimerítő ellenőrzéshez. Egyes tulajdonságokat könnyebb előbb valószínűségi alapon tesztelni, és később bizonyítani. A Forge az ellenőrzést tölcsérként kezeli, nem pedig tisztasági rituáléként. Az olcsó ellenőrzések elutasítják a nyilvánvaló képtelenségeket. Az erősebb ellenőrzések védik a végső jelöltet.
A gyorsaság nem egyetlen szám
A teljesítménnyel kapcsolatos munka nevetségessé válik, ha egyetlen mérőszám uralhat minden beszélgetést. A késleltetés számít. A műveletek száma számít. A memóriahasználat számít. A regiszterterhelés számít. A fordítási idő néha számít. A hordozhatóság számít, ha ugyanannak a kernelnek több háttérrendszeren is futnia kell. Egy jelölt, amely úgy nyer a késleltetésben, hogy úgy égeti a regisztereket, mint egy kis máglya, rossz választás lehet a tényleges célhoz. Egy jelölt, amely apró, de lassú, máshol hasznos lehet. A kontextus továbbra is verhetetlen.
A Forge ezért Pareto-problémaként keretezi az optimalizálást. A motor képes a célok között keresni, ahelyett, hogy azt színlelné, hogy létezik egyetlen univerzális pontszám, amelyet egy nagyon magabiztos táblázatkezelő diktál. A hasznos kimenet nem mindig a leggyorsabb jelölt. Néha ez egy jelöltekből álló család, látható kompromisszumokkal, hogy a mérnök kiválaszthassa azt, amelyik illeszkedik a telepítési korlátozásokhoz.
Ez az oka annak is, hogy nem szeretem a puszta gyorsulási állításokat blogbejegyzésekben. A kutatási oldal leírhatja a belső elvárásokat és a kísérleti célokat, de a nyilvános állításokhoz friss futtatások, aktuális hardver, aktuális fordítókapcsolók és pontos munkaterhelési kontextus kell. Ellenkező esetben a szám emléktárggyá válik. Az emléktárgyak szépek. De nem építészet.
Az őszinte állítás egyébként is erősebb: a Forge arról szól, hogy a keresést reprodukálhatóvá, összehasonlíthatóvá és ellenőrizhetővé tegye. Amikor egy jelölt nyer, tudnunk kell, melyik célban nyert, mely jelölteket győzött le, melyik ellenőrző fogadta el, és melyik háttérrendszert célozza. Ez sokkal hasznosabb, mint egy szám, amely egy prezentáción úszik át, drágának tűnve.
A leszállítás az, ahol a bizonyításokat próbára teszik
A felfedezett implementáció csak akkor hasznos, ha túléli az utat a valódi célpontokig. A Forge kutatása kiterjed a háttérrendszerekre történő leszállításra, mint például az x86-64, a RISC-V, a WASM, a Vulkan GPU-útvonalak, a C és a Verilog. Ez a célpontlista nem dekoráció. Minden háttérrendszernek megvannak a saját korlátai, utasításformái, memóriaviselkedése és hibamódjai. Ugyanannak a specifikációnak meg kell őriznie a jelentését, miközben az implementáció olyanná válik, amit a célpont ténylegesen futtatni tud.
Itt kapcsolódik a szintézis a Dweve stack többi részéhez. A Core hatékony belső ciklusokat akar. A Numerus a determinisztikus numerikus kernelekre összpontosít. A BitWeave bináris vektor- és mátrixműveleteket szeretne, amelyek nem pazarolják a CPU-t. A Kera a számítási gráfok valódi hardverre történő leszállításával foglalkozik. A Forge csak akkor tudja ellátni ezeket a rétegeket, ha a generált implementáció több mint gyors. Egyenértékűnek kell lennie, elég hordozhatónak a kiválasztott célponthoz, és ellenőrizhetőnek, ha valami megváltozik.
Mit jelent ez a csapatoknak
Egy csapat számára az érdekes változás nem az, hogy egy gép gyorsabb kernelt fedezhet fel. Hanem az, hogy a kernelmunka kevésbé függ a folklórtól. Egy szakértő helyett, aki megjegyzi a megfelelő trükköt, a folyamat a következővé válik: add meg a szerződést, keresd meg a teret, mérd meg a jelölteket, bizonyítsd az egyenértékűséget, rögzítsd a kompromisszumot, és generáld a célkódot. Az emberek még mindig döntenek. Csak nem kézzel végzik az összes felfedezést.
Ez azért fontos a műveletek szempontjából, mert a teljesítményadósság drága, és ezt a szervezetek gyakran elrejtik. Egy lassú kernel több szervert jelent. A több szerver több költséget, több energiát, nagyobb telepítési komplexitást és több zajt jelent a tervezésben. Egy rossz optimalizálás incidensekké válik. Egy helyes, de dokumentálatlan trükk jövőbeli migrációs kockázattá válik. A Forge kutatás arra irányul, hogy csökkentse ezt a halom elkerülhető ostobaságot.
Kulturális változás is van. A kézi teljesítménymunka gyakran a hősiességet jutalmazza. Valaki eltűnik a barlangban, és visszatér egy okos bittrükkel. Mindenki tapsol, senki sem érti teljesen, és a cég szerzett egy kis szent tárgyat. A Forge az evidencia felé tolja a folyamatot: itt a spec, itt a keresési útvonal, itt az elutasított jelöltek, itt a verifikáló, itt a kiválasztott háttérrendszer. Kevesebb mitológia. Több bizonylat.
Hol még nehéz a munka
Egyik sem teszi könnyűvé a szintézist. A specifikációk nehezek. Ha a spec rossz, a motor hűségesen felfedezheti a rossz dolgot. A keresési terek felrobbanhatnak. A megoldók időtúlléphetnek. A költségmodellek félrevezethetnek. A háttérrendszerek olyan részleteket fedhetnek fel, amelyekkel az absztrakt kifejezés nem törődött. A verifikáció erős lehet az egyik tartományban, és kínos a másikban. Aki program szintézist árul, mint egy automatát az optimális kódhoz, az vagy kihagyja a nehéz részeket, vagy külön díjat számít fel a csalódásért.
A Forge pontosan azért érdekes, mert közvetlenül szembenéz ezekkel a nehéz részekkel. Több keresési stratégiát kombinál. A verifikációt közel tartja. A célokat kompromisszumként kezeli. Valódi háttérrendszereket céloz meg. Kutatási program marad, mert még mindig tanuljuk, hol húzódik a határ az automatizált felfedezés, az emberi ítélet, a megoldói korlátok és a telepítési valóság között.
Ezt a határt érdemes felfedezni. A szoftveriparban túl sok kis forró ciklus van, túl sok megkettőzött teljesítményfolklór, és túl sok olyan optimalizáció, amelyhez senki sem akar hozzányúlni. Ha a Forge ebből a munkából akár egy részt is megismételhető evidenciális folyamattá tud alakítani, az eredmény nem csak gyorsabb kód. Nyugodtabb kód. A nyugodtabb kód alulértékelt, leginkább azok által, akiket még nem hívtak hajnali 02:17-kor.
Mire van szüksége egy jó Forge-futtatásnak
Egy komoly Forge-kísérlet azelőtt kezdődik, hogy a motor elindulna. A csapatnak valódi kernelt kell hoznia, nem pedig homályos panaszt a teljesítményről. Szükség van reprezentatív bemenetekre, ismert szélső esetekre, célhardverre, aktuális benchmarkokra és arra az üzleti indokra, amiért ez a kernel fontos. Ellenkező esetben a szintézismotor sok időt tölthet egy olyan probléma megoldásával, amellyel valójában senki sem szembesül. A kutatási eszközök sem immunisak a szemétbemenetre. Csak drágábbá teszik a szemét vizsgálatát.
A leghasznosabb bemenet egy kicsi, éles szerződés. Mit kell kiszámítania a függvénynek? Mely algebrai törvények számítanak? Melyik túlcsordulási viselkedés szándékos? Mely tartományok lehetetlenek szerkezetükből adódóan, és melyek csak azért nem fordultak elő, mert az utolsó teszten nem jöttek elő? Mely kimenetek tűrik el a közelítést, és melyek nem? Az a csapat, amelyik nem tud válaszolni ezekre a kérdésekre, valószínűleg még nem rendelkezik optimalizálási problémával. Inkább termék-tisztázási problémája van, amely fordítójelmezt visel.
A jó futtatáshoz célhelyzet is kell. Az x86-64 és a RISC-V nem ugyanaz. A WASM más korlátokat jelent. A Vulkan GPU-útvonalak a formákra és a memóriamozgásra érzékenyek. A Verilog olyan hardverkérdéseket vet fel, amelyekkel a hétköznapi alkalmazáscsapatok ritkán szembesülnek szívesen kávé előtt. A Forge képes felfedezni a célhardverre történő leszállítást, de nem tudja eldönteni a szervezeti prioritásokat. Ha a hordozhatóság fontosabb, mint az egy célra történő sebesség, mondjátok ki. Ha a késleltetés fontosabb, mint a memória, mondjátok ki. Ha a regiszterterhelés a gyakorlati korlát, azt is mondjátok ki. A motor erős, nem gondolatolvasó.
A kimenetet bizonyítékcsomagként kell kezelni. Jelölt, cél, bizonyítási út, elvetett ellenpéldák, háttérrendszer, benchmark-kontextus és nyitott fenntartások. Ez a csomag teszi lehetővé, hogy az emberek józan döntést hozzanak. Néha a nyerő lépés a jelölt elfogadása. Néha a régi kernel megtartása, mert a hordozhatósági kompromisszum nem éri meg. Néha a felfedezés az, hogy a specifikáció túl laza volt. Mindhárom kimenetel hasznos. Csak az egyik néz ki izgalmasnak egy demóban, ezért a demók rossz helyettesítői a mérnöki munkának.
A tanulság
A Forge tanulsága egyszerű: a teljesítmény ne előzze meg a bizonyítást. A keresés erős, de a keresőmotor ellenőrzés nélkül csak egy nagyon energikus módja a hibák létrehozásának. Az ellenőrzés erős, de keresés nélkül arra vár, hogy az emberek jelölteket hozzanak neki. A Forge a kettőt egyesíti, és megkérdezi, milyen kerneleket fedezhetünk fel, ha a gép felfedezhet, de nem hazudhat.
Ez az a kutatás, amelyet érdemes végezni. Típusos specifikációk, jelöltkeresés, bizonyítási tölcsérek, Pareto-célok és háttérrendszer-leszállítás. Nem varázslat. Nem termék-rövidítés. Egy módja annak, hogy jobb kis kódot hozzunk létre csatolt bizonyítékkal.