Takomisen ja haun arvoinen todiste
Vanhan tempun ongelma
Jokaisessa vakavassa ohjelmistojärjestelmässä on muutama koodinpätkä, joilla on merkitystä paljon enemmän kuin niiden koko antaisi ymmärtää. Silmukka, joka suoritetaan miljoonia kertoja. Bittioperaatio pakkauspolussa. Pieni matriisirutiini. Modulaarisen aritmetiikan ydin. Sellaisia asioita, jotka näyttävät vaarattomilta koodikatselmoinnissa ja päättävät sitten hiljaa energialaskun, viivebudjetin tai sen, kuinka monta konetta sinun täytyy ostaa. Hyvin demokraattista, ohjelmisto. Yksi pieni funktio voi pilata kokouksen kaikilta.
Historiallisesti näitä ytimiä parantavat ihmiset. Vanhempi insinööri muistaa tempun jostakin paperista. Joku kaivaa esiin vanhan foorumiviestin. Kirjoitetaan benchmark-sarja. Kokeillaan muutamaa ehdokasta. Nopein voittaa, jos se näyttää edelleen oikealta. Sitten organisaatio jäädyttää sen, koska sen koskettaminen uudelleen tuntuu siltä kuin herättelisi nukkuvaa muuntajaa haarukalla.
Forge on tutkimusta tuon prosessin paremmasta versiosta. Se on ohjelmasynteesimoottori pienille, kriittisille toteutuksille: anna sille tyypitetty spesifikaatio ja ominaisuudet, anna sen etsiä ehdokasohjelmia, mittaa ja vertaile kompromisseja, varmista vastaavuus ja laske sitten löydetty toteutus tärkeisiin kohteisiin. Tärkeä sana ei ole haku. Tärkeä sana on edelleen. Sen on edelleen oltava oikea.
Siksi Forge elää tutkimuksessa. Se ei ole julkinen tuotepainike, johon joku kirjoittaa tee nopeammaksi ja saa ihmeen. Se on synteesityöpöytä kumppanikokeille, ydinten löytämiselle ja tutkimukselle siitä, kuinka pitkälle automatisoitu haku voi mennä, kun se sidotaan varmennukseen benchmark-teatterin sijaan.
Spesifikaatio on lähtöviiva
Optimointi ilman spesifikaatiota on vain uhkapelaamista hienommilla muuttujanimillä. Heti kun fiksu ehdokas ilmestyy, tiimin on tiedettävä, mitä sen on tarkoitus säilyttää. Käsitteleekö se kaikki syötteet vai vain ystävälliset benchmarkista? Kunnioittaako se ylivuotokäyttäytymistä? Onko algebrallinen identiteetti voimassa sillä esityksellä, jota todella käytetään? Säilyttääkö se saman semantiikan, kun se lasketaan eri taustajärjestelmään?
Forge aloittaa tyypitetyistä lausekkeista ja ominaisuuksista, koska haku tarvitsee rajan. Raja määrittää, mikä lasketaan vastaavaksi. Ilman sitä moottori voi löytää jotakin hämmästyttävän nopeaa poistamalla puolet työstä. Tietokoneet ovat erinomaisia pahantahtoisessa myötäilyssä, kun sopimus on epämääräinen.
Hakupuoli on tarkoituksella monikko. Enumeroiva haku on hyödyllinen, kun avaruus on tarpeeksi pieni katettavaksi. CEGIS on hyödyllinen, kun vastaesimerkit voivat ohjata tarkentamista. Geneettinen ohjelmointi ja MCTS tutkivat eri tavoin. ML-ohjattu haku voi oppia kustannusmalleja ja priorisoida lupaavia alueita. Mikään näistä ei ole yleisesti paras. Se ei ole heikkous. Se on sitä, miten haku käyttäytyy todellisessa maailmassa. Jos yksi vasara ratkaisisi jokaisen ytimen, työkalupakit olisivat hyvin tylsiä ja laitteistovalmistajat työttömiä.
Tutkimuskysymys on, miten yhdistää nämä moottorit riittävällä todistuspaineella niin, että tulos ei ole pelkästään nokkela. Syntetisoidun ytimen on selviydyttävä sekä happy path -benchmarkista että epäonnistumispolun varmistajasta. Muuten parannus ei ole insinöörityötä. Se on taikatemppu ylläpitokustannuksella.
Varmistaja on aikuinen huoneessa
Forge käyttää varmennuspinoa, koska yksikään tarkistus ei riitä kaikille alueille. Nopeat esimerkit ovat halpoja ja hyödyllisiä. Ominaisuustestit löytävät laajoja virheluokkia ja tiivistävät vastaesimerkit ihmisen luettaviksi. SMT-ratkaisijat, kuten Z3 ja CVC5, voivat todistaa ekvivalenssin silloin, kun koodaus on käsiteltävissä. Tyhjentävä tarkistus on käytännöllistä pienillä alueilla. E-graafin ekvivalenssikyllästys antaa toisen reitin algebralliseen ekvivalenssiin.
Pino on tärkeä, koska ytimet epäonnistuvat ärsyttävillä tavoilla. Ehdokas voi läpäistä jokaisen tavallisen vertailuarvon ja silti olla väärä reunatapauksessa. Se voi olla oikea etumerkittömille syötteille ja väärä etumerkillisille. Se voi olla oikea matemaattisessa kunnassa ja väärä sen jälkeen, kun valittu esitystapa ylivuotaa. Se voi olla oikea ennen alennusta ja hienovaraisesti väärä käskynvalintapäätöksen jälkeen. Varmennin on olemassa, koska optimismi ei ole testausstrategia. Tarkistimme. Toistuvasti. Se pitää edelleen paikkansa.
On myös käytännön syy pitää useita todistusreittejä. Formaalit menetelmät ovat tehokkaita, mutta eivät ilmaisia. Jotkin koodaukset aikakatkaistaan. Jotkin alueet ovat liian suuria tyhjentävään tarkistukseen. Jotkin ominaisuudet on helpompi testata ensin todennäköisyyspohjaisesti ja todistaa myöhemmin. Forge käsittelee varmennusta suppilona, ei puhtausrituaalina. Halvat tarkistukset hylkäävät ilmeisen hölynpölyn. Vahvemmat tarkistukset suojaavat lopullista ehdokasta.
Nopeus ei ole yksi luku
Suorituskykytyöstä tulee typerää, kun yhden mittarin annetaan hallita jokaista keskustelua. Viiveellä on merkitystä. Operaatiomäärällä on merkitystä. Muistinkäytöllä on merkitystä. Rekisteripaineella on merkitystä. Käännösajalla on joskus merkitystä. Siirrettävyydellä on merkitystä, kun saman ytimen on toimittava useammalla kuin yhdellä taustajärjestelmällä. Ehdokas, joka voittaa viiveessä polttamalla rekistereitä kuin pieni kokko, voi olla väärä varsinaiselle kohteelle. Ehdokas, joka on pieni mutta hidas, voi olla hyödyllinen jossain muualla. Konteksti pysyy voittamattomana.
Forge kehystää siksi optimoinnin Pareto-ongelmana. Moottori voi etsiä tavoitteiden välillä sen sijaan, että teeskentelisi olevan yksi universaali pistemäärä, jonka hyvin itsevarma laskentataulukko on antanut. Hyödyllinen tulos ei ole aina yksittäinen nopein ehdokas. Joskus se on ehdokasperhe, jossa on näkyvät kompromissit, jotta insinööri voi valita sen, joka sopii käyttöönoton rajoitteisiin.
Tästä syystä en myöskään pidä paljaista nopeutusväitteistä blogikirjoituksissa. Tutkimussivu voi kuvata sisäisiä odotuksia ja kokeellisia tavoitteita, mutta julkiset väitteet vaativat tuoreita ajokertoja, nykyistä laitteistoa, nykyisiä kääntäjän lippuja ja tarkan työmääräkontekstin. Muuten luvusta tulee matkamuisto. Matkamuistot ovat kivoja. Ne eivät ole arkkitehtuuria.
Rehellinen väite on silti vahvempi: Forge tekee hausta toistettavaa, vertailukelpoista ja tarkistettavaa. Kun ehdokas voittaa, meidän pitäisi tietää, minkä tavoitteen se voitti, mitkä ehdokkaat se päihitti, mikä varmennin sen hyväksyi ja mille taustajärjestelmälle se on suunnattu. Se on paljon hyödyllisempää kuin luku, joka leijuu läpi diaesityksen näyttäen kalliilta.
Alennus on paikka, jossa todisteet joutuvat koetukselle
Löydetty toteutus on hyödyllinen vain, jos se selviää matkasta oikeisiin kohdealustoihin. Forge-tutkimus kattaa alustojen kuten x86-64, RISC-V, WASM, Vulkan-GPU-polku, C ja Verilog alennuksen. Tämä kohdelista ei ole koriste. Jokaisella taustajärjestelmällä on omat rajoitteensa, käskyrakenteensa, muistikäyttäytymisensä ja vikatilansa. Saman spesifikaation on säilytettävä merkityksensä, kun toteutuksesta tulee jotain, jota kohde pystyy todella ajamaan.
Tässä kohtaa synteesi kytkeytyy muuhun Dweve-pinoon. Core haluaa tehokkaita sisäsilmukoita. Numerus välittää deterministisistä numeerisista ytimistä. BitWeave haluaa binääri- ja matriisioperaatioita, jotka eivät tuhlaa suoritinta. Kera välittää laskentagraafien alentamisesta oikealle laitteistolle. Forge voi ruokkia näitä kerroksia vain, jos tuotettu toteutus on muutakin kuin nopea. Sen on oltava vastaava, riittävän siirrettävä valitulle kohteelle ja tarkastettavissa, kun jokin muuttuu.
Mitä tämä muuttaa tiimeille
Tiimille kiinnostava muutos ei ole se, että kone saattaa löytää nopeamman ytimen. Se on se, että ydintyö muuttuu vähemmän riippuvaiseksi perimätiedosta. Sen sijaan, että yksi asiantuntija muistaisi oikean tempun, prosessista tulee: määrittele sopimus, hae avaruudesta, mittaa ehdokkaat, todista vastaavuus, kirjaa kompromissi ja tuota kohdekoodi. Ihmiset päättävät edelleen. He vain lopettavat kaiken löytämisen käsin.
Tämä on tärkeää operaatioille, koska suorituskykyvelka on kallista tavalla, jonka organisaatiot usein piilottavat. Hidas ydin tarkoittaa lisää palvelimia. Lisää palvelimia tarkoittaa lisää kustannuksia, energiaa, käyttöönoton monimutkaisuutta ja melua suunnittelussa. Väärä optimointi tarkoittaa häiriöitä. Oikea mutta dokumentoimaton temppu tarkoittaa tulevaa siirtymäriskiä. Forge on tutkimusta tuon vältettävissä olevan hölynpölyn kasautuman vähentämiseksi.
Mukana on myös kulttuurinen muutos. Manuaalinen suorituskykytyö palkitsee usein sankariteot. Joku katoaa luolaan ja palaa nokkelan bittitempun kanssa. Kaikki taputtavat, kukaan ei täysin ymmärrä sitä, ja yritys on hankkinut pienen pyhän esineen. Forge työntää prosessia kohti todisteita: tässä on speksi, tässä on hakureitti, tässä ovat hylätyt ehdokkaat, tässä on varmennin, tässä on valittu taustajärjestelmä. Vähemmän mytologiaa. Enemmän kuittia.
Missä työ on edelleen vaikeaa
Mikään tästä ei tee synteesistä helppoa. Spesifikaatiot ovat vaikeita. Jos speksi on väärä, moottori voi uskollisesti löytää väärän asian. Hakutilat voivat räjähtää. Ratkaisijat voivat aikakatkaista. Kustannusmallit voivat johtaa harhaan. Taustajärjestelmät voivat paljastaa yksityiskohtia, joista abstrakti lauseke ei välittänyt. Varmennus voi olla vahvaa yhdellä alueella ja hankalaa toisella. Jokainen, joka myy ohjelmasynteesiä optimaalisen koodin automaattina, joko ohittaa vaikeat osat tai veloittaa ylimääräistä pettymyksestä.
Forge on kiinnostava juuri siksi, että se kohtaa nämä vaikeat osat suoraan. Se yhdistää useita hakustrategioita. Se pitää varmennuksen lähellä. Se käsittelee tavoitteita kompromisseina. Se kohdistaa oikeisiin taustajärjestelmiin. Se pysyy tutkimusohjelmana, koska opimme edelleen, missä raja kulkee automatisoidun löytämisen, inhimillisen harkinnan, ratkaisijoiden rajoitusten ja käyttöönoton todellisuuden välillä.
Tämä raja on tutkimisen arvoinen. Ohjelmistoalalla on liikaa pieniä kuumia silmukoita, liikaa toistettua suorituskyvyn perimätietoa ja liikaa optimointeja, joihin kukaan ei halua koskea uudelleen. Jos Forge voi muuttaa edes osan tästä työstä toistettavaksi todisteprosessiksi, tulos ei ole vain nopeampaa koodia. Se on rauhallisempaa koodia. Rauhallinen koodi on aliarvostettua, enimmäkseen niiden toimesta, joita ei ole hälytetty kello 02:17.
Mitä hyvä Forge-ajo vaatii
Vakava Forge-koe alkaa ennen kuin moottori käynnistyy. Tiimin on tuotava mukaan oikea ydin, ei epämääräistä valitusta suorituskyvystä. Tarvitaan edustavia syötteitä, tunnettuja reunatapauksia, kohdelaitteisto, nykyiset vertailuarvot ja liiketoiminnallinen syy sille, miksi tämä ydin on tärkeä. Muuten synteesimoottori voi käyttää paljon aikaa ongelman ratkaisemiseen, jota kenelläkään ei oikeasti ole. Tutkimustyökalut eivät ole immuuneja roskasyötteelle. Ne vain tekevät roskan tarkastelusta kalliimpaa.
Hyödyllisin syöte on pieni ja tarkka määrittely. Mitä funktion pitäisi laskea? Mitkä algebralliset lait ovat olennaisia? Mikä ylivuotokäyttäytyminen on tarkoituksellista? Mitkä alueet ovat mahdottomia rakenteensa puolesta ja mitkä vain eivät esiintyneet edellisessä testiajossa? Mitkä tulokset sietävät likiarvoa ja mitkä eivät? Tiimi, joka ei osaa vastata näihin kysymyksiin, ei todennäköisesti vielä omaa optimointiongelmaa. Sillä on tuotteen selkeytysongelma, joka on pukeutunut kääntäjän asuun.
Hyvä ajo vaatii myös kohdeasennon. x86-64 ja RISC-V eivät ole sama asia. WASM:lla on erilaiset rajoitteet. Vulkan-GPU-polku välittää muodoista ja muistin liikkeestä. Verilog nostaa esiin laitteistokysymyksiä, joista tavalliset sovellustiimit eivät yleensä nauti ennen kahvia. Forge voi tutkia kohdelaskentaa, mutta se ei voi päättää organisatorisia prioriteetteja. Jos siirrettävyys on tärkeämpää kuin yhden kohteen nopeus, sano se. Jos viive voittaa muistin, sano se. Jos rekisteripaine on käytännön raja, sano sekin. Moottori on tehokas, ei ajatustenlukija.
Tulosta tulisi käsitellä todistepakettina. Ehdokas, tavoite, todistusreitti, hylätyt vastaesimerkit, taustajärjestelmä, vertailuarvojen konteksti ja avoimet varaukset. Tämä paketti on se, minkä avulla ihmiset voivat tehdä järkevän päätöksen. Joskus voittava siirto on ottaa ehdokas käyttöön. Joskus se on pitää vanha ydin, koska siirrettävyyskompromissi ei ole sen arvoinen. Joskus löydös on se, että määrittely oli liian löyhä. Kaikki kolme lopputulosta ovat hyödyllisiä. Vain yksi niistä näyttää jännittävältä demossa, ja siksi demot ovat huono korvike insinöörityölle.
Opetus
Forgen opetus on yksinkertainen: suorituskyvyn ei pitäisi ohittaa todistusta. Haku on tehokasta, mutta hakukone ilman varmennusta on vain erittäin energinen tapa luoda bugeja. Varmennus on tehokasta, mutta ilman hakua se odottaa, että ihmiset tuovat sille ehdokkaita. Forge yhdistää nämä kaksi ja kysyy, mitä ytimiä voimme löytää, kun koneen annetaan tutkia, mutta ei valehdella.
Sellaista tutkimusta kannattaa tehdä. Tyypitetyt määrittelyt, ehdokashaku, todistussuppilot, Pareto-tavoitteet ja taustajärjestelmän laskenta. Ei taikuutta. Ei tuotteen oikotietä. Tapa tehdä parempaa pientä koodia, johon on liitetty todisteita.