Kera ja laskemisen työ
Vikaraportti, joka ei ollutkaan vika
Tarina alkaa yleensä numerosta, joka on lähes oikein. Ei täysin väärin. Ei niin rikki, että kojelauta muuttuisi punaiseksi. Lähes oikein kalliilla tavalla: sellaista väärin olemista, joka antaa yhden tiimin julkaista, toisen tiimin epäröidä ja auditoijan kysyä, miksi vastaus muuttui, kun sama malli siirrettiin koneelta toiselle.
Eräs buildi ajetaan x86-palvelimella ja tuottaa arvon. Seuraava buildi ajetaan ARM-kannettavalla ja tuottaa arvon, joka on riittävän lähellä, että demo säilyy. GPU-polku on nopeampi, mutta pyöristää laskennan eri tavalla. FPGA-polku on houkutteleva ajoituksen kannalta, mutta yhtäkkiä ohjelmistotiimi keskustelee laitteistosta. Jokainen osaa selittää pienen osan erosta. Kukaan ei omista koko polkua lähteestä tulokseen.
Siihen tilaan Kera on rakennettu. Ei malli-ideaan, ei markkinointikalvoon, ei paperiin tulevaisuuden kääntäjästä, vaan kääntäjätyöhön, joka alkaa, kun tiimi sanoo, että saman laskennan on toimittava eri koneilla ja tarkoitettava edelleen samaa asiaa. Tämä velvoite tarvitsee omistajan. Kääntäjän lupaus ei ole, että alennus on tyylikästä. Lupaus on, että alennusta käsitellään työnä.
Alennus on se osa kääntäjää, jossa hyvä kieli-intentio muuttuu käskyiksi, joita kohde voi suorittaa. Se on myös paikka, jossa epämääräiset väitteet tulevat näkyviksi. Jos tuloksen pitää olla bitti bitiltä identtinen CPU:n, GPU:n, FPGA:n ja WebAssemblyn välillä, kääntäjä ei voi kohauttaa olkiaan kohde-eroille. Sen on kannettava riittävästi rakennetta päättääkseen, mikä saa muuttua ja mikä ei saa muuttua. Sen on tunnettava muistitilat, efektit, opkoodit, datan liikkuminen, kohderajoitukset ja kuitit, jotka osoittavat, että kaksi buildia ovat sama laskenta.
Kiusaus on kutsua tätä siirrettävyyskerrokseksi. Se on liian vähän. Siirrettävyys tarkoittaa, että ohjelma toimii muuallakin. Kera tähtää vaikeampaan väitteeseen: ohjelma esitetään sisältöosoitteisena graafina, käännetään .keg-artefaktiksi, alennetaan useille taustaosille ja tuottaa silti saman vastauksen. Keittiö vaihtuu. Resepti ei.
Keskiosa, jota kukaan ei halua myydä
Ensimmäinen keskustelu vakavan ostajan kanssa alkaa harvoin syntaksista. Se alkaa sotkusta. On malli, jolla on merkitystä. On simulaatio, joka oli ennen tutkimusta ja josta on tullut operatiivista. On riskilaskelma, jonka tuloksen ei enää sallita vaihdella koneittain. On reunalaitteisto, joka ei voi kantaa koko pilviruntimea. On tiimi, joka haluaa kiihdyttimen, mutta ei voi varaa uudelleenkirjoitusta joka kerta, kun kiihdytin muuttuu.
Useimmat työkalut saavat tämän näyttämään käyttöönotto-ongelmalta. Valitse kohde, vie malli, korjaa runtime, hyväksy jonkin verran vaihtelua ja kirjoita sitten dokumentti, joka selittää poikkeukset. Dokumentti kasvaa. Testimatriisi kasvaa. Asiantuntijoiden määrä kasvaa. Lopulta organisaatio maksaa heterogeenisyydestä kahdesti: kerran ostaessaan laitteiston ja toisen kerran yrittäessään osoittaa, että laitteisto teki saman työn.
Kera aloittaa vastakkaisesta päästä. Kera-sivu kutsuu sitä staattisesti tyypitetyksi järjestelmäkieleksi, jossa on graafipohjainen, sisältöosoitteinen IR. Tämä ilmaus on tärkeä, koska graafi ei ole koristeellinen kääntäjäkaavio. Se on suoritettava objekti. Lähdekoodi alennetaan operaatioiden suunnatuiksi asyklisiksi graafeiksi, jotka tallennetaan .keg-tiedostoina. Jokainen solmu kantaa määritellyn rakenteen. Päällekkäinen työ voidaan poistaa rakenteellisesti. Sama graafi voidaan alentaa CPU:lle, GPU:lle, FPGA:lle ja WASM:lle käsittelemättä jokaista kohdetta erillisenä pienenä maailmankaikkeutena.
Siksi Keran on toimittava kuin vakava kääntäjäinfrastruktuuri, ei kuin kaavio. Epämukava välimaasto on se, missä asiakas elää. Tokenisoinnin on säilytettävä tavupaikat. Jäsentämisen on palveltava sekä työkaluja että kääntämistä. Tyypintarkistuksen on hylättävä muoto- ja reunapoikkeamat ennen kuin niistä tulee ajonaikaisia tapahtumia. Lainatarkistuksen on ymmärrettävä omistajuus isäntä-, laite-, kiinnitetyn ja yhtenäisen muistin välillä. Optimoinnin on oltava toistettavaa. Serialisoinnin on annettava organisaatiolle artefakti, jonka se voi säilyttää.
Mikään tästä ei ole dramaattinen otsikko. Se on paljon hyödyllisempää kuin otsikko. Se tarkoittaa, että kun työkuorma siirtyy kehityksestä tuotantoon tai CPU-perustasta GPU-polkuun, kääntäjällä on vakaa vertailukohde: graafin sormenjälki. Jos sormenjälki täsmää, työ on sama työ. Se on yhteinen valvontapiste, jonka insinööri, ostaja ja tilintarkastaja kaikki ymmärtävät.
Graafi on kuitti, ei kuva
Vanha tapa selittää ohjelma on näyttää lähdekoodi ja pyytää lukijaa luottamaan kääntäjään. Kera-sivu palaa jatkuvasti toiseen objektiin: graafiin. Jokainen operaatio on solmu. Reunat ilmaisevat riippuvuuksia. Graafilla on sisältö. Sisällöllä on hajautusarvo. Hajautusarvosta tulee sormenjälki, joka kulkee rakennuksen mukana.
Tämä kuulostaa sisäiseltä koneistolta, kunnes seisot vaatimustenmukaisuustiimin vieressä. Vaatimustenmukaisuustiimi ei halua tietää, että toimittajalla on hieno kääntäjäarkkitehtuuri. Se haluaa tietää, onko viime kuussa hyväksytty laskenta sama laskenta, joka pyörii tänään. Graafin sormenjälki on silta näiden maailmojen välillä. Se ei ole kuvakaappaus kääntäjästä. Se on tiivis tapa sanoa: tämä operaatioryhmä, nämä tyypit, nämä syötteet, nämä attribuutit, tämä riippuvuusrakenne.
Solmumalli on tarkoituksellisen tiukka. Solmu on skeemaversio, opcode, tulostekuvaajat, syötehajautusarvot ja attribuuttikartat kanonisessa järjestyksessä. Tavut hajautetaan SHA3-256:lla erotetuilla etuliitteillä, joten solmu-, alue- ja graafihajautusarvot elävät erillisissä nimiavaruuksissa. Jos kahdella solmulla on sama opcode, samat syötteet ja samat attribuutit, niillä on sama hajautusarvo. Kaksoiskappaleen lisääminen palauttaa olemassa olevan merkinnän. Yhteisen alilausekkeen eliminoinnista tulee esitystavan seuraus, ei myöhemmin lisätty sankarillinen välivaihe.
Tällainen yksityiskohta muuttaa suunnittelujärjestelmän sellaiseksi, johon ihmiset voivat luottaa. Ostaja ei osta kääntäjäkaaviota. Ostaja ostaa vähemmän väittelyä siitä, onko laskenta muuttunut. Kehittäjä ei osta iskulausetta deterministisestä tekoälystä. Kehittäjä ostaa graafimuodon, jossa samuus voidaan tarkistaa, tallentaa ja jota työkalut voivat käyttää. .keg-tiedosto ei siis ole toteutuksen jälkiajatus. Se on kannettava tallenne työstä.
Kahdeksan pientä ovea ennen kuin kohde ilmestyy
Kun ihmiset kuvittelevat kääntäjän, he hyppäävät usein suoraan taustapäähän. He kuvittelevat hetken, jolloin koodista tulee AVX, PTX, Verilog tai WASM. Se hetki on tärkeä, mutta se on myöhään tarinassa. Suurin osa kääntäjän työstä on tapahtunut jo ennen sitä, hiljaisissa vaiheissa, jotka ratkaisevat, voiko taustapäähän luottaa.
Kera alkaa UTF-8-tietoisella lekserillä, joka muuntaa lähdekoodin tokeneiksi täydellisellä trivia-seurannalla ja virheenpalautuksella. Se kuulostaa editorin putkistolta, ja sitä se on. Se on myös työkaluketjun luotettavuutta. Jos jokainen tavun sijainti säilytetään, diagnostiikka, muotoilu, inkrementaalinen uudelleenjäsennys ja kielipalvelimen toiminta voivat olla linjassa sen kanssa, mitä käyttäjä todella kirjoitti. Kääntäjä, joka menettää lähdekoodin muodon varhain, maksaa siitä tappiosta kaikkialla muualla.
Jäsennin on tapahtumapohjainen: rekursiivinen laskeutuminen Pratt-lausekejäsentämisellä lähettää Start-, Token-, Finish- ja Error-tapahtumia sen sijaan, että se rakentaisi yhden AST:n, jota kaikkien pitäisi jakaa. Tapahtumavirta ruokkii puurakentajaa, muotoilijaa ja kielipalvelinta itsenäisesti. Vihreä puu on häviötön, ja se säilyttää tokenit ja trivian. Graafirakentaja kävelee sitten sen puun läpi, ylläpitää nimien selvitystä ja luo Region-solmun jokaista funktiota kohden.
Vasta sen jälkeen lähdekoodista tulee graafi, jota kääntäjä kantaa. Rakenteellinen tyyppitarkistus validoi yhteensopivuuden operaatioreunojen ja tensorimuotojen rajoitteiden välillä. Tyypit täsmäävät vain, kun niiden kanoniset hajautusarvot ovat identtiset. Lainatarkistin valvoo yhtä omistajaa arvoa kohden, ei rinnakkaisia muuttuvia viittauksia, ja omistussääntöjä muistitilojen välillä. Efektimerkinnät tarkistetaan johdonmukaisuuden varalta. Sivuvaikutuksia ei jätetä maun tai käytännön varaan.
Optimoinnin passienhallinta tekee sitten tunnistettavan kääntäjän työn: vakioiden laskostuksen, yhteisten alilausekkeiden eliminoinnin, kuolleen koodin eliminoinnin, sisäänkääntämisen, vektorisoinnin ja silmukoiden fuusion kiintopistekierrossa. Tärkeä ilmaus ei ole passien luettelo. Se on se, mitä tapahtuu jokaisen passin jälkeen: graafin invarianttivalidaattori tarkistaa hajautusarvojen johdonmukaisuuden ja riippuvuuksien eheyden. Optimoinnin on sallittua parantaa graafia, ei tehdä siitä salaperäistä.
Lopuksi kohdekohtaiset koodigeneraattorit tuottavat natiivikoodia, PTX:ää, Verilogia tai WASM:ia, ja optimoitu graafi serialisoidaan .keg-tiedostoon osiotaulukon kanssa. Tiedosto alkaa taikabiteillä KEG\0 ja sisältää osiot merkkijonoille, tyypeille, attribuuteille, solmuille, alueille ja vienneille. Se on polku, jonka tiimin on omistettava ennen kuin se voi rehellisesti puhua kohteista.
Kohteet eivät ole tarroja dialla
Kohdeluettelo on helppo kirjoittaa ja vaikea ansaita. CPU, GPU, FPGA ja WASM mahtuvat siististi tuotekorttiin. Niihin alentaminen on se, missä lasku piilee. Jokaisella kohteella on omat tapansa, vahvuutensa ja vikatilansa. Kääntäjä, joka haluaa deterministisen heterogeenisen suorituksen, ei voi kohdella näitä tapoja jonkun muun ongelmana.
Suorittimilla Kera tuottaa natiivia konekoodia x86-64:lle ja ARM64:lle, ja RISC-V Vector löytyy teknisestä dokumentista. x86-polku valitsee SSE2:n, AVX2:n tai AVX-512:n; ARM-polku käyttää NEONia; rekisterinvaraus ja ajastin ovat yhteisiä. Tuoteväite ei ole vain se, että binääri on olemassa. Väite on, että kohdekohtaiset SIMD-ytimet valitaan samalla kun graafi pysyy samana laskentana.
GPU:illa lähdemateriaali mainitsee PTX-generoinnin CUDA:lle ja ROCm:lle, ja tensorisydämiä käytetään, kun ytimen muoto sen sallii. Tuo viimeinen lause tekee työtä. Laitteistokiihdytys ei ole taikapölyä. Ytimen muoto joko sopii tensorisydänpolkuun tai ei sovi. Kääntäjän on kerrottava tämä rehellisesti, siirrettävä dataa isännän ja laitteen välillä tarvittaessa, ja pidettävä graafin sormenjälki todisteena siitä, mitä suoritetaan.
FPGA:lla alennuspolusta tulee laitteistokeskustelu: Verilog-synteesi, resurssiarviointi, ajoitusanalyysi ja putkiston ajastus ennustettavaa, syklintarkkaa käyttäytymistä varten. Tämä on sellainen kohde, jossa käsien heiluttelu on erityisen kallista. Jos ostaja tarvitsee kovan reaaliajan, kääntäjän pinnan on puhuttava sykleissä, resursseissa ja putkistoissa, ei vain nopeudessa. Keran tarina tekee FPGA:sta saman graafin taustajärjestelmän sen sijaan, että toinen tiimi kirjoittaisi sen uudelleen.
WASM:ssä sivu mainitsee 128-bittisen SIMD:n reuna- ja selainkäyttöön. Tämä on tärkeää, koska reuna on paikka, jossa käyttöönoton todellisuus usein törmää puhtauteen. Selain, pieni laite tai rajoitettu suoritusympäristö ei aina voi isännöidä samaa pinoa kuin palvelin. Graafinatiivinen alennuspolku antaa tiimille keinon viedä sama laskenta tuohon ympäristöön ilman, että reunasta tulee toinen tuote.
Determinismin on selviydyttävä menestyksestä
Determinismi on helppo luvata pienessä huoneessa. Siitä tulee vaikeampaa, kun tuote menestyy. Käyttäjiä tulee lisää. Laitteistoa ilmestyy lisää. Malli siirtyy sirulta toiselle. Yhdelle ympäristölle kirjoitetun testipohjan on katettava toinen. Harmittoman näköinen optimointi muuttaa redusoinnin järjestystä. Nopea polku ilmestyy yhteen suoritusympäristöön mutta ei toiseen.
Kera-sivu esittää determinismin bittitasolla samanlaisena kaikilla alustoilla. Tämä ei ole kosmeettinen väite. Se muuttaa tuotteen velvoitteita. Primitiiviaritmetiikalla on määritelty tarkkuussemantiikka kaikilla kohdealustoilla. Reduktioilla on määritelty tasapelien ratkaisusääntö, joten ajoitus ja laitteisto eivät muuta tulosta. Neuroverkkojen primitiiveillä on deterministiset toteutukset CPU:lla, GPU:lla, FPGA:lla ja WASM:lla. Graafi tarkoittaa samaa asiaa riippumatta siitä, missä se suoritetaan.
Tästä syystä määrittelemätön käyttäytyminen, roskienkerääjän pysäytykset ja piilovaikutukset eivät ole pieniä kielivalintoja. Ne ovat halkeamia suorituspinnassa. Kera-sivu sanoo, ettei LLVM-riippuvuutta, roskienkerääjää eikä määrittelemätöntä käyttäytymistä ole. Eksplisiittiset tyypit, eksplisiittiset vaikutukset ja omistajuus muistialueiden yli ovat tuoteohjaimia. Ne vähentävät niitä paikkoja, joissa tulos voi muuttua sillä välin, kun kaikki katsovat muualle.
Tässä on myös inhimillinen puoli. Kun robottiohjain muuttaa käyttäytymistään laitteiden välillä, kun rahoitusprosessi pyöristää yhden sentin eri tavalla, kun tieteellistä tulosta ei voi toistaa arvioija tai kun pelisimulaatio eroaa kohdealustojen välillä, väite ei oikeastaan koske kääntäjäteoriaa. Se koskee institutionaalista luottamusta. Keran kuluttajateksti käyttää yksinkertaisia tarinoita, koska taustalla oleva ongelma on helppo tuntea: samat ohjeet, sama vastaus, millä tahansa omistamallasi tietokoneella.
Tämän luottamuksen on kestettävä kiihdytys. Jos suorituskyky vaatii tiimejä luopumaan determinismistä, tuote on vain siirtänyt riskin. Kera pyrkii pitämään suorituskyvyn ja determinismin samassa sopimuksessa tekemällä graafista merkityksen yksikön ja kohdepolusta suorituksen yksikön.
Turvallisuus on osa kääntämistä
Kääntäjäkeskusteluissa turvallisuus eristetään usein ajonaikaiseksi työksi. Keran lähdemateriaali ei tee näin. Se puhuu kyvykkyyspohjaisesta turvallisuudesta, SecurityManagerista, oletusarvoisesti kieltävästä portista, PolicyBuilderista, seccomp BPF:stä, Linux-nimiavaruuksista ja säikeen turvallisesta peukaloinnin paljastavasta auditointilokista kiinteän kapasiteetin rengaspuskurissa. Nämä sanat kuuluvat suunnittelutarinaan, koska kääntäminen ei pääty, kun käskyt on tuotettu. Tuotetun työn on silti toimittava rajojen sisällä.
Kyvykkyystunnisteet myönnetään käynnistyksessä. Etuoikeutetut toimet vaativat eksplisiittisen kyvykkyyden. Pääsäännöt ilmoitetaan etukäteen. BPF-suodatin rajoittaa järjestelmäkutsuja. Nimiavaruuseristys erottaa prosessi-, liitos- ja verkkonäkymät. Turvallisuuteen liittyvät tapahtumat päätyvät auditointilokiin. Lyhyt lause on: mikään ei ole sallittua oletusarvoisesti.
Tämä on tärkeää heterogeeniselle suoritukselle, koska kohdealustat luovat pintoja. CPU-prosessi, GPU-siirto, FPGA-polku, selainajoympäristö ja hajautettu työ eivät epäonnistu samalla tavalla. Tuotteen on pidettävä käytäntö kiinnitettynä työhön sen liikkuessa. Jos graafi kertoo, mitä laskenta on, ajonaikaiset ohjaimet kertovat, mitä laskenta saa tehdä.
On myös operatiivinen syy tuoda turvallisuus kääntäjätarinaan. Tiimit eivät halua yhtä tuotetta kääntämiseen, toista käytäntöihin, kolmatta lokitukseen ja neljättä selityksiin, jos niiden välisistä saumoista tulee paikka, johon vaaratilanteet piiloutuvat. Kera-sivu ei väitä ratkaisevansa kaikkea turvallisuutta. Se tekee jotain kapeampaa ja hyödyllisempää: se tekee käyttöoikeuksista eksplisiittisiä ja auditoituja siinä suoritusympäristössä, jota kääntäjä ruokkii.
Hajautettu työ on edelleen kääntämistä
Tekninen tiedote nimeää hajautetun suorituksen, rengasallreduktion ja tarkistuspisteen palautuksen. Toisessa tuotteessa ne voisivat olla esitekohteita. Kerassa ne kuuluvat samaan kääntämiskeskusteluun, koska rinnakkaisuus muuttaa laskennan muotoa. Data-, malli- ja putkistoparallelismi eivät ole vain tapoja nopeuttaa. Ne ovat tapoja jakaa työ menettämättä alkuperäisen graafin merkitystä.
Kun suuri työ ajetaan usealla koneella ja yksi solmu kaatuu, palautuminen tarkistuspisteestä ei ole mukavuuskysymys. Se on osa laskennan tekemistä toimivaksi. Jos tulokset aggregoidaan luotettavasti, aggregoinnin semantiikka on määriteltävä. Jos graafi on sisältöosoitteellinen, hajautetun polun on säilytettävä graafin identiteetti sen sijaan, että se keksisi toisen todellisuuden, kun työ siirtyy koneelta toiselle.
Tässä tuotteen tulkinta selkeytyy. Kera ei ole syntaksikerros, johon on lisätty hajautettu ominaisuus. Se pyrkii tekemään laskennasta siirrettävää sekä muodon että laitteiston suhteen: yksi ohjelma, yksi graafi, useita suorituskohteita ja tarkistettavissa oleva tietue. Hajautettu suoritus on yksi paikka lisää, jossa alennuksen on kannettava suoritussopimus.
Se muuttaa myös henkilöstökysymyksen. Ilman yhteistä käännöspolkua vain yhdellä alustalla ilmenevä bugi voi vaatia ihmisiä, jotka tuntevat sirun, työkaluketjun ja ajonaikaisen ympäristön kaikki kerralla. Yhden graafin ja yhteisen polun kanssa kysymys on tarkempi: muuttuiko graafi, muuttuiko alennuspolku vai rikkoiko kohde määritellyn semantiikan? Paremmat kysymykset eivät poista kovaa työtä. Ne estävät kovan työn leviämästä sattumanvaraisesti.
Miksi jonkun on omistettava polku
Alennus ei voi jäädä omistajattomaksi, kun se kantaa tuloksia, joihin ihmiset luottavat. Graafi, joka toimii CPU:lla, GPU:lla, FPGA:lla ja WASM:lla, tarvitsee enemmän kuin nokkelan esityksen. Se tarvitsee dokumentaatiota, diagnostiikkaa, kohdeväitteitä, editorikäyttäytymistä, koodigenerointia, tietoturvaohjauksia, tukikeskusteluja ja tavan kertoa ostajalle tarkalleen, mikä muuttui, kun tulos muuttuu.
Se ei tee työstä vähemmän teknistä. Se tekee teknisestä työstä sitovampaa. Kera on tällä hetkellä kaupallinen Dweve-tuote, ei avoimen lähdekoodin julkaisu: kaikki oikeudet pidätetään, saatavilla kaupallisella lisenssillä, valmistettu Alankomaissa ja tarkoitettu organisaatioille, jotka tarvitsevat graafipolun tuettuna eivätkä vain julkaistuna. Jos sivulla mainitaan Rust 2021, graafi-IR, mukautettu JIT, ei LLVM:ää, CPU/GPU/FPGA/WASM, efektiseuranta, omistajuus muistiavaruuksien yli, kyvykkyysturvallisuus, hajautettu suoritus, C- ja Python-upotus, CLI-työnkulut, editorituki ja LSP-työkalut, nämä eivät ole koristeellisia sisäisiä yksityiskohtia. Ne ovat velvoitteita, joiden on kestettävä todellisten työmäärien arviointi.
Kyvykkyystietolomake on tässä huolellinen. Se kuvaa suunnittelutavoitteita ja kehottaa varmistamaan ne omalla työmäärälläsi. Tämä pidättyväisyys on tärkeää. Se on paljon terveellisempää kuin teeskennellä, että jokainen vertailuluku siirtyy sellaisenaan. Järjestelmän pitäisi antaa tiimeille tapa mitata, tarkastaa ja vertailla omassa ympäristössään, ei pyytää heitä hyväksymään yleismaailmallista nopeustarinaa.
Jonkun on omistettava se polku, koska jokainen kohde pyrkii tekemään lähteestä vähemmän yleismaailmallisen. Kera on paikka, jossa nämä kohde-erot muuttuvat eksplisiittiseksi kääntäjätyöksi sen sijaan, että ne olisivat bugiraportin jälkeen kierrätettyä perimätietoa.
Päivä, jolloin graafista tulee sopimus
Kuvittele alkuperäinen bugiraportti uudelleen, mutta Kera on jo työnkulussa. Rahoitustiimi hyväksyy riskilaskelman. Graafin sormenjälki tallennetaan. Ensimmäinen käyttöönotto ajetaan CPU:lla. Myöhemmin GPU-polku otetaan käyttöön sijoitussalkun analyysiä varten. Myöhemmin vielä FPGA-polku otetaan käyttöön matalamman viiveen hinnoittelua varten. Kysymys jokaisessa vaiheessa ei ole se, kuulostaako uusi laitteisto vaikuttavalta. Kysymys on se, alennetaanko sama graafi ja pitävätkö kohdesemantiikat tuloksen identtisenä.
Keskustelu muuttuu. Alustatiimi voi puhua ajoituksesta ja kustannuksista. Kääntäjätiimi voi puhua taustaosista. Vaatimustenmukaisuustiimi voi puhua sormenjäljestä. Liiketoiminnan omistaja voi kysyä, onko laitteiston vaihtaminen operatiivinen päätös vai uudelleenkirjoitus. Tuote antaa kaikille heille yhden objektin, johon osoittaa.
Se on sisältöosoitteellisen IR:n hiljainen arvo. Se muuttaa alustojen välisen suorituksen sarjasta suostuttelevia selityksiä tallenteeksi. Se tekee graafista kuitin. Se antaa saman .keg-tiedoston ruokkia jokaista taustajärjestelmää. Se antaa organisaatiolle lähtökohdan, joka kuuluu laskennalle eikä yksittäiselle koneelle.
Mikään kääntäjä ei voi poistaa insinööriarvioinnin tarvetta. Tiimien on edelleen valittava kohteet huolellisesti, testattava työkuormia rehellisesti, ymmärrettävä kohdealustojen rajat ja päätettävä, mitkä alueet vaativat bittitarkkaa samanlaisuutta. Mutta Kera voi tehdä näistä päätöksistä eksplisiittisiä. Se voi estää suorituskykymigraatiota muuttumasta vahingossa semanttiseksi migraatioksi.
Alaslaskennan opetus
Kera on tärkeä, koska vaikea osa ei ole nerokkaan alaslaskentaidean keksiminen. Vaikea osa on viedä se idea läpi kaikkien niiden tylsien paikkojen, joissa insinöörityöstä tulee joko luotettavaa tai perimätietoa: diagnostiikka, vihreät puut, tyyppitiivisteet, lainatarkistus, kiintopisteoptimointi, invarianttien validointi, .keg-serialisointi, taustajärjestelmän emissio, tietoturvakäytännöt, auditointilokit, editorituki ja kohdekohtainen suoritus.
Alaslaskenta on työtä, koska jokainen kohde yrittää tehdä lähteestä vähemmän universaalin. Deterministinen kääntäjäsuunnittelu on sitä kurinalaisuutta, että tämän ei anneta tapahtua hiljaa. CPU haluaa vektoreita. GPU haluaa ytimiä. FPGA haluaa syklejä. WASM haluaa rajoitteita. Organisaatio haluaa yhden vastauksen. Keran tehtävä on säilyttää laskennan merkitys samalla kun jokainen kohde saa tehdä sitä, missä se on hyvä.
Se on insinöörin muoto, ei paperilla oleva abstraktio. Sillä on ostaja, vikatila, tiedostomuoto, kääntäjäpolku ja toiminnalliset seuraukset. Lupaus ei ole, että laitteistosta tulee yksinkertaista. Lupaus on, että monimutkaisuus on esitetty, laskettu alas, tarkistettu ja omistettu.
Kun seuraava melkein oikea luku saapuu, tiimin ei pitäisi joutua aloittamaan perimätiedosta siitä, mikä kone ajoi mitäkin. Sen pitäisi aloittaa graafista. Täsmäsikö sormenjälki? Mikä taustajärjestelmä emittoi koodin? Mitkä ominaisuudet myönnettiin? Mitä kohdesemantiikkaa sovellettiin? Mikä artefakti tallennettiin? Nämä ovat tuotekysymyksiä. Kera on olemassa, koska ne ovat myös kääntäjäkysymyksiä.