Forge ir paieška, įrodanti savo vertę
Senos gudrybės problema
Kiekviena rimta programinės įrangos sistema turi keletą kodo dalių, kurios yra kur kas svarbesnės, nei rodo jų dydis. Ciklas, kuris vykdomas milijonus kartų. Bitų operacija glaudinimo kelyje. Maža matricos procedūra. Modulinės aritmetikos branduolys. Tokie dalykai, kurie kodo peržiūroje atrodo nekenksmingi, o paskui tyliai nulemia energijos sąskaitą, delsos biudžetą arba mašinų, kurias reikia įsigyti, skaičių. Labai demokratiška, ta programinė įranga. Viena maža funkcija gali sugadinti susitikimą visiems.
Istoriškai tuos branduolius tobulina žmonės. Vyresnysis inžinierius prisimena gudrybę iš straipsnio. Kažkas kasinėjasi po seną forumo įrašą. Parašoma etalonų rinkinys. Išbandomi keli kandidatai. Greičiausias laimi, jei vis dar atrodo teisingas. Tada organizacija jį įšaldo, nes vėl jį liesti atrodo kaip miegantį transformatorių badyti šakute.
Forge yra tyrimai, kaip pagerinti tą procesą. Tai programų sintezės variklis mažiems, kritiniams įgyvendinimams: duokite jam tipizuotą specifikaciją ir savybes, leiskite jam ieškoti kandidatų programų, išmatuoti ir palyginti kompromisus, patikrinti ekvivalentiškumą, tada nuleisti atrastą įgyvendinimą į svarbius taikinius. Svarbus žodis yra ne paieška. Svarbus žodis yra vis dar. Jis vis dar turi būti teisingas.
Štai kodėl Forge gyvena tyrimuose. Tai ne viešas produkto mygtukas, kuriame kas nors įveda padaryk greičiau ir gauna stebuklą. Tai sintezės darbo stalas partnerių eksperimentams, branduolių atradimui ir tyrimams, kiek toli gali nueiti automatizuota paieška, kai ji susieta su patikrinimu, o ne su etalonų teatru.
Specifikacija yra starto linija
Optimizavimas be specifikacijos yra tiesiog lošimas su gražesniais kintamųjų pavadinimais. Kai tik atsiranda sumanus kandidatas, komanda turi žinoti, ką jis turi išsaugoti. Ar jis apdoroja kiekvieną įvestį ar tik draugiškas iš etalonų? Ar jis gerbia perpildymo elgesį? Ar algebrinė tapatybė galioja pagal faktiškai naudojamą atvaizdavimą? Ar jis išlaiko tą pačią semantiką, kai nuleidžiamas į kitą backendą?
Forge pradeda nuo tipizuotų išraiškų ir savybių, nes paieškai reikia ribos. Riba nusako, kas laikoma ekvivalentišku. Be jos variklis gali rasti ką nors stebėtinai greito, ištrindamas pusę darbo. Kompiuteriai puikiai moka piktavališkai paklusti, kai sutartis neaiški.
Paieškos pusė sąmoningai daugiskaita. Išvardijamoji paieška naudinga, kai erdvė pakankamai maža, kad ją būtų galima aprėpti. CEGIS naudingas, kai kontrpavyzdžiai gali padėti patobulinti. Genetinis programavimas ir MCTS tyrinėja kitaip. ML valdoma paieška gali išmokti kaštų modelius ir teikti pirmenybę perspektyvioms sritims. Nė vienas iš jų nėra visuotinai geriausias. Tai ne silpnybė. Taip paieška elgiasi realiame pasaulyje. Jei vienas plaktukas išspręstų kiekvieną branduolį, įrankių dėžės būtų labai nuobodžios, o techninės įrangos pardavėjai liktų be darbo.
Tyrimų klausimas yra, kaip sujungti tuos variklius su pakankamu įrodymų spaudimu, kad rezultatas būtų ne tik sumanus. Sintezuotas branduolys turi išgyventi ir laimingą kelią etalonuose, ir nelaimingą kelią tikrintuve. Kitaip patobulinimas nėra inžinerija. Tai magijos triukas su priežiūros kaštais.
Tikrintuvas yra suaugęs kambaryje
„Forge“ naudoja verifikavimo krūvą, nes jokio vieno patikrinimo negana kiekvienai sričiai. Greiti pavyzdžiai yra pigūs ir naudingi. Savybių testai aptinka plačias klaidų klases ir suspaudžia kontrpavyzdžius į tai, ką žmogus gali perskaityti. SMT sprendėjai, tokie kaip Z3 ir CVC5, gali įrodyti ekvivalentiškumą ten, kur kodavimas yra įveikiamas. Išsamus tikrinimas yra praktiškas mažoms sritims. E-grafo lygybės prisotinimas suteikia dar vieną kelią per algebrinį ekvivalentiškumą.
Krūva svarbi, nes branduoliai žlunga erzinančiais būdais. Kandidatas gali išlaikyti kiekvieną įprastą etaloną ir vis tiek būti neteisingas kraštiniu atveju. Jis gali būti teisingas neženkliems įvesties duomenims ir neteisingas ženkliems. Jis gali būti teisingas matematinėje srityje ir neteisingas po to, kai pasirinktas vaizdavimas persipildo. Jis gali būti teisingas prieš žeminimą ir subtiliai neteisingas po instrukcijų parinkimo sprendimo. Verifikatorius egzistuoja, nes optimizmas nėra testavimo strategija. Mes tikrinome. Pakartotinai. Tai išlieka tiesa.
Taip pat yra praktinė priežastis turėti kelis įrodymų kelius. Formalūs metodai yra galingi, bet jie nėra nemokami. Kai kurie kodavimai pasibaigia laikui. Kai kurios sritys yra per didelės išsamiam tikrinimui. Kai kurias savybes lengviau iš pradžių išbandyti tikimybiškai, o įrodyti vėliau. „Forge“ verifikavimą traktuoja kaip piltuvą, o ne kaip grynumo ritualą. Pigūs patikrinimai atmeta akivaizdžias nesąmones. Stipresni patikrinimai apsaugo galutinį kandidatą.
Greitas nėra vienas skaičius
Darbas su našumu tampa kvailas, kai vienai metrikai leidžiama dominuoti kiekviename pokalbyje. Latencija svarbi. Operacijų skaičius svarbus. Atminties naudojimas svarbus. Registrų spaudimas svarbus. Kompiliavimo laikas kartais svarbus. Perkeliamumas svarbus, kai tas pats branduolys turi veikti daugiau nei viename backende. Kandidatas, kuris laimi latenciją degindamas registrus kaip mažą laužą, gali būti neteisingas tikram tikslui. Kandidatas, kuris yra mažas, bet lėtas, gali būti naudingas kitur. Kontekstas lieka nenugalėtas.
Todėl „Forge“ optimizavimą formuluoja kaip Pareto problemą. Variklis gali ieškoti per tikslus, o ne apsimesti, kad yra vienas universalus balas, nuleistas iš labai pasitikinčios skaičiuoklės. Naudingas rezultatas ne visada yra vienintelis greičiausias kandidatas. Kartais tai yra kandidatų šeima su matomais kompromisais, kad inžinierius galėtų pasirinkti tą, kuris atitinka diegimo apribojimą.
Tai taip pat priežastis, kodėl man nepatinka pliki pagreitėjimo teiginiai tinklaraščio įrašuose. Tyrimų puslapis gali aprašyti vidinius lūkesčius ir eksperimentinius tikslus, tačiau viešiems teiginiams reikia naujų paleidimų, dabartinės aparatinės įrangos, dabartinių kompiliatoriaus vėliavų ir tikslios darbo krūvio konteksto. Priešingu atveju skaičius tampa suvenyru. Suvenyrai yra gražūs. Jie nėra architektūra.
Nuoširdus teiginys vis tiek stipresnis: „Forge“ yra apie paieškos padarymą atkuriama, palyginama ir patikrinama. Kai kandidatas laimi, turėtume žinoti, kurį tikslą jis laimėjo, kuriuos kandidatus įveikė, kuris verifikatorius jį priėmė ir kuriam backendui jis skirtas. Tai daug naudingiau nei skaičius, plūduriuojantis per skaidrių rinkinį ir atrodantis brangus.
Žeminimas yra vieta, kur įrodymai išbandomi
A discovered implementation is only useful if it survives the trip to real targets. Forge research covers lowering to backends such as x86-64, RISC-V, WASM, Vulkan GPU paths, C and Verilog. That target list is not decoration. Each backend has its own constraints, instruction shapes, memory behaviour, and failure modes. The same specification has to keep its meaning while the implementation becomes something the target can actually run.
This is where synthesis connects to the rest of the Dweve stack. Core wants efficient inner loops. Numerus cares about deterministic numeric kernels. BitWeave wants binary vector and matrix operations that do not waste the CPU. Kera cares about lowering computation graphs to real hardware. Forge can feed those layers only if the generated implementation is more than fast. It must be equivalent, portable enough for the chosen target, and inspectable when something changes.
What this changes for teams
For a team, the interesting shift is not that a machine might discover a faster kernel. It is that kernel work becomes less dependent on folklore. Instead of one expert remembering the right trick, the process becomes: state the contract, search the space, measure candidates, prove equivalence, record the tradeoff, and generate target code. Humans still decide. They just stop doing all discovery by hand.
That matters for operationsbecause performance debt is expensive in a way organizations often hide. A slow kernel becomes more servers. More servers become more cost, more energy, more deployment complexity, and more noise in planning. A wrong optimization becomes incidents. A correct but undocumented trick becomes a future migration risk. Forge is research into reducing that pile of avoidable nonsense.
There is a cultural change too. Manual performance work often rewards heroics. Someone disappears into the cave and returns with a cleverbit hack. Everyone applauds, nobody fully understands it, and the company has acquired a small sacred object. Forge pushes the process toward evidence: here is the spec, here is the search route, here are the rejected candidates, here is the verifier, here is the selected backend. Less mythology. More receipts.
Where the work is still hard
None of this makes synthesis easy. Specifications are hard. If the spec is wrong, the engine can faithfully discover the wrong thing. Search spaces can explode. Solvers can time out. Cost models can mislead. Backends can expose details the abstract expression did not care about. Verification can be strong in one domain and awkward in another. Anyone selling program synthesis as a vending machine for optimal code is either skipping the hard parts or charging extra for disappointment.
Forge is interesting precisely because it faces those hard parts directly. It combines several search strategies. It keeps verification close. It treats objectives as tradeoffs. It targets real backends. It remains a research program because we are still learning where the boundary sits between automated discovery, human judgement, solver limits, and deployment reality.
That boundary is worth exploring. The software industry has too many small hot loops, too much duplicated performance folklore, and too many optimizations that nobody wants to touch again. If Forge can turn even part of that work into a repeatable evidence process, the result is not just faster code. It is calmer code. Calmer code is underrated, mostly by people who have not been paged at 02:17.
Ko reikia geram Forge paleidimui
Rimtas Forge eksperimentas prasideda dar prieš paleidžiant variklį. Komanda turi atsinešti tikrą branduolį, o ne miglotą skundą dėl našumo. Reikia reprezentatyvių įvesties duomenų, žinomų kraštinių atvejų, tikslinės aparatinės įrangos, dabartinių etalonų ir verslo priežasties, kodėl šis branduolys svarbus. Priešingu atveju sintezės variklis gali praleisti daug laiko spręsdamas problemą, kurios niekas iš tikrųjų neturi. Tyrimų įrankiai nėra apsaugoti nuo netinkamų įvesties duomenų. Jie tik padaro netinkamus duomenis brangesnius nagrinėti.
Naudingiausia įvestis yra maža, aiški specifikacija. Ką funkcija turėtų apskaičiuoti? Kurie algebriniai dėsniai svarbūs? Kuris perpildymo elgesys yra tyčinis? Kurie diapazonai neįmanomi pagal konstrukciją, o kurie tiesiog nepasitaikė paskutinio testo metu? Kurie rezultatai gali pakęsti apytikslį skaičiavimą, o kurie ne? Komanda, kuri negali atsakyti į šiuos klausimus, tikriausiai dar neturi optimizavimo problemos. Ji turi produkto patikslinimo problemą, vilkinčią kompiliatoriaus kepurę.
Geram paleidimui taip pat reikia tikslinės pozicijos. x86-64 ir RISC-V nėra tas pats. WASM turi skirtingus apribojimus. Vulkan GPU keliai rūpinasi formomis ir atminties judėjimu. Verilog kelia aparatinės įrangos klausimų, kurių įprastos programų komandos retai mėgaujasi prieš kavą. Forge gali tyrinėti tikslinį žeminimą, bet negali nuspręsti organizacinių prioritetų. Jei perkeliamumas svarbesnis už greitį vienoje platformoje, pasakykite tai. Jei delsa svarbesnė už atmintį, pasakykite tai. Jei registrų spaudimas yra praktinė riba, pasakykite ir tai. Variklis galingas, ne aiškiaregis.
Rezultatas turėtų būti traktuojamas kaip įrodymų paketas. Kandidatas, tikslas, įrodymo kelias, atmesti priešpavyzdžiai, backendas, etalono kontekstas ir atviros išlygos. Šis paketas leidžia žmonėms priimti protingą sprendimą. Kartais laimintis žingsnis yra priimti kandidatą. Kartais reikia pasilikti seną branduolį, nes perkeliamumo kompromisas nevertas. Kartais atradimas yra tas, kad specifikacija buvo pernelyg laisva. Visi trys rezultatai yra naudingi. Tik vienas iš jų atrodo įdomus demonstracijoje, todėl demonstracijos yra prastas inžinerijos pakaitalas.
Pamoka
Forge pamoka paprasta: našumas neturėtų aplenkti įrodymų. Paieška yra galinga, bet paieškos variklis be patikros yra tik labai energingas būdas kurti klaidas. Patikra yra galinga, bet be paieškos ji laukia, kol žmonės atneš kandidatų. Forge sujungia abu ir klausia, kokius branduolius galime atrasti, kai mašinai leidžiama tyrinėti, bet neleidžiama meluoti.
Tai tyrimas, kurį verta daryti. Tipizuotos specifikacijos, kandidatų paieška, įrodymų piltuvėliai, Pareto tikslai ir backend žeminimas. Ne magija. Ne produkto spartusis kelias. Būdas kurti geresnį mažą kodą su pridedamais įrodymais.