Kera a práca znižovania
Bug report, ktorý nebol bugom
Príbeh sa zvyčajne začína číslom, ktoré je takmer správne. Nie úplne zlé. Nie rozbité tak, že by dashboard sčervenal. Takmer správne tým drahým spôsobom: taký druh chyby, ktorý jednej zostave umožní vydať sa, ďalšej váhať a audítorovi položiť otázku, prečo sa odpoveď zmenila, keď sa rovnaký model presunul z jedného stroja na druhý.
Jedna zostava beží na x86 serveri a vyprodukuje hodnotu. Ďalšia zostava beží na ARM notebooku a vyprodukuje hodnotu dostatočne blízku na to, aby demo prežilo. GPU cesta je rýchlejšia, ale zaokrúhľuje výpočet inak. FPGA cesta je atraktívna z hľadiska časovania, ale softvérový tím zrazu vedie hardvérovú konverzáciu. Každý vie vysvetliť malý kúsok rozdielu. Nikto nevlastní celú cestu od zdroja po výsledok.
Presne pre tento priestor je postavený Kera. Nie pre nápad modelu, nie pre marketingový slajd, nie pre článok o budúcom kompilátore, ale pre kompilátorovú prácu, ktorá začína vo chvíli, keď tím povie, že rovnaký výpočet musí bežať na rôznych strojoch a stále znamenať to isté. Táto povinnosť potrebuje vlastníka. Sľub kompilátora nie je, že lowering je elegantný. Sľub je, že lowering sa berie ako práca.
Lowering je časť kompilátora, kde sa pekný zámer jazyka stáva inštrukciami, ktoré cieľ dokáže vykonať. Je to tiež miesto, kde sa vágne tvrdenia stávajú viditeľnými. Ak má byť výsledok bit po bite identický naprieč CPU, GPU, FPGA a WebAssembly, kompilátor si nemôže dovoliť mávnuť rukou nad rozdielmi cieľov. Musí niesť dostatok štruktúry na to, aby rozhodol, čo sa môže zmeniť a čo sa zmeniť nesmie. Musí poznať pamäťové priestory, efekty, opkódy, presuny dát, obmedzenia cieľov a potvrdenia, ktoré dokazujú, že dve zostavy sú rovnaký výpočet.
Lákavá verzia príbehu je nazvať to vrstvou prenosnosti. To je príliš málo. Prenosnosť hovorí, že program beží aj inde. Kera mieri na tvrdšie tvrdenie: program je reprezentovaný ako graf adresovaný obsahom, skompilovaný do .keg artefaktu, znížený na viacero backendov a stále produkuje rovnakú odpoveď. Kuchyňa sa mení. Recept nie.
Stred, ktorý nikto nechce predávať
Prvý rozhovor s vážnym kupcom sa málokedy začína syntaxou. Začína sa neporiadkom. Existuje model, na ktorom záleží. Existuje simulácia, ktorá bola kedysi výskumom a stala sa prevádzkovou. Existuje výpočet rizika, ktorého výsledok sa už nesmie líšiť podľa stroja. Existuje edge nasadenie, ktoré nemôže niesť plný cloud runtime. Existuje tím, ktorý chce akcelerátor, ale nemôže si dovoliť prepísať všetko zakaždým, keď sa akcelerátor zmení.
Väčšina nástrojov to robí ako problém nasadenia. Vyberte cieľ, exportujte model, opravte runtime, akceptujte určitú odchýlku a potom napíšte dokument vysvetľujúci výnimky. Dokument rastie. Testovacia matica rastie. Počet špecialistov rastie. Nakoniec organizácia platí za heterogenitu dvakrát: raz, keď kupuje hardvér, a druhýkrát, keď sa snaží dokázať, že hardvér vykonal rovnakú prácu.
Kera začína z opačného konca. Stránka Kera to nazýva staticky typovaný systémový jazyk s grafovo-natívnym IR adresovaným obsahom. Táto fráza je dôležitá, pretože graf nie je dekoratívny kompilátorový diagram. Je to spustiteľný objekt. Zdrojový kód sa znižuje na orientované acyklické grafy operácií, uložené ako .keg súbory. Každý uzol nesie definovanú štruktúru. Duplicitná práca sa dá štrukturálne eliminovať. Rovnaký graf sa dá znížiť na CPU, GPU, FPGA a WASM bez toho, aby sa každý cieľ považoval za samostatný malý vesmír.
Preto sa Kera musí správať ako seriózna kompilátorová infraštruktúra, nie ako diagram. Nepríjemný stred je miesto, kde žije zákazník. Tokenizácia musí zachovávať pozície bajtov. Parsovanie musí napájať nástroje aj kompiláciu. Typová kontrola musí odmietnuť nezrovnalosti tvarov a hrán skôr, než sa stanú udalosťami za behu. Kontrola požičiavania musí rozumieť vlastníctvu naprieč pamäťou hostiteľa, zariadenia, pripnutou a zjednotenou pamäťou. Optimalizácia musí byť opakovateľná. Serializácia musí organizácii poskytnúť artefakt, ktorý si môže ponechať.
Nič z toho nie je dramatický titulok. Je to oveľa užitočnejšie ako titulok. Znamená to, že keď sa pracovná záťaž presunie z vývoja do produkcie, alebo zo základnej línie CPU na cestu GPU, kompilátor má stabilnú vec na porovnanie: odtlačok grafu. Ak sa odtlačok zhoduje, práca je rovnaká práca. To je spoločný kontrolný bod, ktorému rozumie inžinier, kupujúci aj audítor.
Graf je účtenka, nie obrázok
Starý spôsob vysvetľovania programu je ukázať zdroj a požiadať čitateľa, aby dôveroval kompilátoru. Stránka Kera sa stále vracia k inému objektu: grafu. Každá operácia je uzol. Hrany vyjadrujú závislosti. Graf má obsah. Obsah má hash. Hash sa stáva odtlačkom, ktorý putuje celým buildom.
Toto znie ako vnútorná mechanika, kým nestojíte vedľa tímu pre dodržiavanie predpisov. Tím pre dodržiavanie predpisov nechce vedieť, že dodávateľ má peknú kompilátorovú architektúru. Chce vedieť, či výpočet schválený minulý mesiac je výpočet, ktorý beží dnes. Odtlačok grafu je most medzi týmito svetmi. Nie je to snímka obrazovky kompilátora. Je to kompaktný spôsob, ako povedať: táto množina operácií, tieto typy, tieto vstupy, tieto atribúty, táto štruktúra závislostí.
Model uzlov je zámerne prísny. Uzol je verzia schémy, opcode, výstupné deskriptory, vstupné hashe a mapy atribútov usporiadané v kanonickom poradí. Bajty sú hashované pomocou SHA3-256 pod doménovo oddelenými prefixmi, takže hashe uzlov, regiónov a grafov žijú v oddelených menných priestoroch. Ak majú dva uzly rovnaký opcode, vstupy a atribúty, majú rovnaký hash. Vloženie duplikátu vráti existujúci záznam. Eliminácia spoločných podvýrazov sa stáva dôsledkom reprezentácie, nie hrdinským prechodom pridaným neskôr.
Toto je druh detailu, ktorý mení inžiniersky systém na niečo, na čo sa ľudia môžu spoľahnúť. Kupujúci nekupuje diagram kompilátora. Kupujúci kupuje menej hádok o tom, či sa výpočet zmenil. Vývojár nekupuje slogan o deterministickej AI. Vývojár kupuje formát grafu, kde sa rovnakosť dá skontrolovať, uložiť a použiť nástrojmi. Súbor .keg preto nie je dodatočný nápad implementácie. Je to prenosný záznam práce.
Osem malých dverí predtým, než sa objaví cieľ
Keď si ľudia predstavia kompilátor, často preskočia rovno na backend. Predstavia si moment, keď sa kód stane AVX, PTX, Verilog alebo WASM. Tento moment je dôležitý, ale prichádza neskoro v príbehu. Väčšina práce kompilátora sa už vtedy stala, v tichých fázach, ktoré rozhodujú o tom, či možno backendu dôverovať.
Kera začína lexerom pracujúcim s UTF-8, ktorý konvertuje zdroj na tokeny s úplným sledovaním trivia a obnovou chýb. To znie ako editorová inštalácia, a aj ňou je. Je to však aj spoľahlivosť nástrojového reťazca. Ak je zachovaná každá pozícia bajtu, diagnostika, formátovanie, inkrementálne preanalyzovanie a správanie jazykového servera môžu zodpovedať tomu, čo používateľ skutočne napísal. Kompilátor, ktorý stratí tvar zdroja skoro, za túto stratu platí všade inde.
Parser je založený na udalostiach: rekurzívny zostup s Prattovým parsovaním výrazov generuje udalosti Start, Token, Finish a Error namiesto vytvárania jediného AST, ktorý musia všetci zdieľať. Prúd udalostí napája staviteľa stromu, formátovač a jazykový server nezávisle. Zelený strom je bezstratový, zachováva tokeny a triviu. Staviteľ grafu potom prechádza týmto stromom, udržiava rozlíšenie mien a vytvára uzol Region pre každú funkciu.
Až potom sa zdroj stane grafom, ktorý kompilátor nesie. Štrukturálna typová kontrola overuje kompatibilitu cez hrany operácií a obmedzenia tvarov tenzorov. Typy sa zhodujú iba vtedy, keď sú ich kanonické hashe identické. Kontrola požičiavania vynucuje jedného vlastníka na hodnotu, žiadne aliasované mutovateľné referencie a pravidlá vlastníctva cez pamäťové priestory. Anotácie efektov sa kontrolujú na konzistentnosť. Vedľajšie efekty nie sú ponechané na vkus alebo konvenciu.
Správca optimalizačných priechodov potom robí rozpoznateľnú prácu kompilátora: konštantnú propagáciu, elimináciu spoločných podvýrazov, elimináciu mŕtveho kódu, inlining, vektorizáciu a fúziu slučiek v slučke s pevným bodom. Dôležitá fráza nie je zoznam priechodov. Je to to, čo sa stane po každom priechode: validátor invariantov grafu kontroluje konzistentnosť hashov a integritu závislostí. Optimalizácia môže graf zlepšiť, nie ho urobiť záhadným.
Nakoniec generátory kódu špecifické pre cieľ generujú natívny kód, PTX, Verilog alebo WASM a optimalizovaný graf sa serializuje do súboru .keg s tabuľkou sekcií. Súbor začína magickými bajtmi KEG\0 a nesie sekcie pre reťazce, typy, atribúty, uzly, regióny a exporty. To je cesta, ktorú musí tím vlastniť, kým môže čestne hovoriť o cieľoch.
Ciele nie sú nálepky na snímke
Zoznam cieľov sa ľahko píše a ťažko zaslúži. CPU, GPU, FPGA a WASM sa úhľadne zmestia na produktovú kartu. Zníženie na ne je miesto, kde sa skrýva faktúra. Každý cieľ má svoje vlastné zvyky, silné stránky a spôsoby zlyhania. Kompilátor, ktorý chce deterministické heterogénne vykonávanie, nemôže tieto zvyky považovať za cudzí problém.
Na CPU Kera generuje natívny strojový kód pre x86-64 a ARM64, pričom RISC-V Vector je v technickom liste. Cesta x86 vyberá SSE2, AVX2 alebo AVX-512; cesta ARM používa NEON; alokátor registrov a plánovač sú zdieľané. Tvrdenie produktu nie je len to, že binárka existuje. Tvrdenie je, že sa vyberajú SIMD jadrá špecifické pre daný cieľ, zatiaľ čo graf zostáva rovnakým výpočtom.
Na GPU zdrojový materiál uvádza generovanie PTX pre CUDA a ROCm, pričom tensor cores sa používajú, keď to tvar jadra umožňuje. Táto posledná veta robí prácu. Hardvérová akcelerácia nie je čarovný prach. Tvar jadra buď zapadá do cesty tensor cores, alebo nie. Kompilátor to musí čestne odhaliť, presúvať dáta medzi hostiteľom a zariadením, keď je to potrebné, a stále si ponechať odtlačok grafu ako dôkaz toho, čo sa vykonáva.
Na FPGA sa cesta znižovania stáva hardvérovým rozhovorom: syntéza Verilog, odhad zdrojov, analýza časovania a plánovanie pipeline pre predvídateľné správanie s presnými cyklami. Toto je druh cieľa, kde je mávanie rukou obzvlášť drahé. Ak kupujúci potrebuje tvrdý reálny čas, povrch kompilátora musí hovoriť v cykloch, zdrojoch a pipeline, nielen v rýchlosti. Príbeh Kera robí z FPGA backend toho istého grafu namiesto prepísania iným tímom.
Na WASM stránka uvádza 128-bitové SIMD pre edge a nasadenie v prehliadači. To je dôležité, pretože edge je miesto, kde sa realita nasadenia často stretáva s čistotou. Prehliadač, malé zariadenie alebo obmedzený runtime nemôžu vždy hostiť rovnaký stack ako server. Cesta znižovania natívna pre graf dáva tímu spôsob, ako preniesť rovnaký výpočet do tohto prostredia bez toho, aby sa edge stal druhým produktom.
Determinizmus musí prežiť úspech
Determinizmus sa v malej miestnosti sľubuje ľahko. Stáva sa ťažším, keď produkt uspeje. Prichádza viac používateľov. Objavuje sa viac hardvéru. Model sa presúva z jedného čipu na druhý. Testovacia základňa napísaná pre jedno prostredie musí pokryť ďalšie. Optimalizácia, ktorá vyzerá neškodne, zmení poradie redukcie. Rýchla cesta sa objaví v jednom runtime, ale nie v inom.
Stránka Kera prezentuje determinizmus ako bit po bite naprieč platformami. Toto nie je len kozmetické tvrdenie. Mení to produktové záväzky. Primitívna aritmetika má definovanú sémantiku presnosti na všetkých cieľových platformách. Redukcie majú definované pravidlá na rozhodovanie pri rovnosti, takže plánovanie a hardvér nemenia výsledok. Primitíva neurónových sietí majú deterministické implementácie na CPU, GPU, FPGA a WASM. Graf znamená to isté nech beží kdekoľvek.
Preto nedefinované správanie, pauzy garbage collectora a implicitné vedľajšie účinky nie sú malé jazykové preferencie. Sú to trhliny v povrchu vykonávania. Stránka Kera hovorí, že žiadna závislosť od LLVM, žiadny garbage collector, žiadne nedefinované správanie. Explicitné typy, explicitné účinky a vlastníctvo naprieč pamäťovými priestormi sú produktové kontroly. Znižujú počet miest, kde sa výsledok môže zmeniť, zatiaľ čo sa všetci pozerajú inam.
Je tu aj ľudská stránka. Keď sa správanie riadiaceho systému robota mení medzi zariadeniami, keď finančný pracovný postup zaokrúhli jeden cent inak, keď vedecký výsledok nedokáže zopakovať recenzent alebo keď sa herná simulácia líši medzi cieľovými platformami, argument nie je v skutočnosti o teórii kompilátorov. Je o inštitucionálnej dôvere. Spotrebiteľský text Kera používa jednoduché príbehy, pretože základný problém je jednoduché cítiť: rovnaké inštrukcie, rovnaká odpoveď, na akomkoľvek počítači, ktorý vlastníte.
Táto dôvera musí prežiť zrýchlenie. Ak výkon vyžaduje, aby tímy opustili determinizmus, produkt len presunul riziko. Kera sa snaží udržať výkon a determinizmus v tej istej zmluve tým, že graf je jednotkou významu a cieľová cesta jednotkou vykonávania.
Bezpečnosť je súčasťou zostavovania
Diskusie o kompilátoroch často izolujú bezpečnosť ako prácu za behu. Zdrojový materiál Kera to nerobí. Hovorí o bezpečnosti založenej na schopnostiach, SecurityManager, bráne s predvoleným odmietnutím, PolicyBuilder, seccomp BPF, Linux namespaces a bezpečnostnom audítorskom logu odolnom voči manipulácii s pevnou kapacitou kruhového buffera. Tieto slová patria do inžinierskeho príbehu, pretože zostavovanie nekončí, keď sú inštrukcie vygenerované. Vygenerovaná práca stále musí bežať s hranicami.
Tokeny schopností sa udeľujú pri spustení. Privilegované akcie vyžadujú explicitnú schopnosť. Pravidlá prístupu sú deklarované vopred. BPF filter obmedzuje systémové volania. Izolácia namespace oddeľuje pohľady na proces, mount a sieť. Udalosti týkajúce sa bezpečnosti sa zaznamenávajú do audítorského logu. Krátka veta je: nič nie je povolené predvolene.
To je dôležité pre heterogénne vykonávanie, pretože cieľové platformy vytvárajú povrchy. Proces CPU, prenos GPU, cesta FPGA, prostredie prehliadača a distribuovaná úloha nezlyhávajú rovnakým spôsobom. Produkt musí udržať politiku pripojenú k práci, keď sa pohybuje. Ak graf hovorí, čo výpočet je, ovládacie prvky runtime hovoria, čo výpočet môže robiť.
Existuje aj prevádzkový dôvod priniesť bezpečnosť do príbehu kompilátora. Tímy nechcú jeden produkt na kompiláciu, ďalší na politiku, ďalší na logovanie a ďalší na vysvetlenie, ak sa švy medzi nimi stanú miestom, kde sa skrývajú incidenty. Stránka Kera netvrdí, že rieši všetku bezpečnosť. Robí niečo užšie a užitočnejšie: robí povolenia explicitnými a auditovanými v prostredí vykonávania, ktoré kompilátor napája.
Distribuovaná práca je stále zostavovanie
Technický list uvádza distribuované vykonávanie, ring allreduce a obnovu z kontrolných bodov. V inom produkte by to mohli byť propagačné položky. V Kera patria do tej istej diskusie o zostavovaní, pretože paralelizmus mení tvar výpočtu. Dátový, modelový a pipeline paralelizmus nie sú len spôsoby, ako ísť rýchlejšie. Sú to spôsoby, ako rozdeliť prácu bez straty významu pôvodného grafu.
Ak veľká úloha beží na mnohých strojoch a jeden uzol zlyhá, obnovenie z kontrolného bodu nie je pohodlie. Je to súčasť toho, aby bol výpočet prevádzkyschopný. Ak sa výsledky spoľahlivo agregujú, sémantika agregácie musí byť definovaná. Ak je graf adresovaný obsahom, distribuovaná cesta musí zachovať identitu grafu, nie vytvárať druhú realitu, akonáhle úloha opustí jeden stroj.
Tu sa objasňuje interpretácia produktu. Kera nie je syntaktická vrstva s distribuovaným doplnkom. Snaží sa urobiť výpočet prenositeľným naprieč tvarom aj hardvérom: jeden program, jeden graf, viacero cieľov vykonávania a záznam, ktorý možno skontrolovať. Distribuované vykonávanie je ďalším miestom, kde musí znižovanie niesť vykonávaciu zmluvu.
Mení to aj personálny príbeh. Bez spoločnej kompilačnej cesty môže chyba, ktorá sa prejaví iba na jednej platforme, vyžadovať ľudí, ktorí poznajú čip, nástrojový reťazec aj runtime naraz. S jedným grafom a spoločnou cestou je otázka ostrejšia: zmenil sa graf, zmenila sa cesta znižovania, alebo cieľ porušil definovanú sémantiku? Lepšie otázky neodstraňujú tvrdú prácu. Zastavujú to, aby sa tvrdá práca šírila náhodne.
Prečo musí niekto vlastniť cestu
Znižovanie nemôže zostať bez vlastníka, akonáhle nesie výsledky, na ktoré sa ľudia spoliehajú. Graf, ktorý beží na CPU, GPU, FPGA a WASM, potrebuje viac než dômyselnú reprezentáciu. Potrebuje dokumentáciu, diagnostiku, tvrdenia o cieľoch, správanie editora, generovanie kódu, bezpečnostné kontroly, podporné konverzácie a spôsob, ako kupujúcemu presne povedať, čo sa zmenilo, keď sa zmení výsledok.
To nerobí prácu menej technickou. Robí technickú prácu záväznejšou. Kera je v súčasnosti komerčný produkt Dweve, nie open-source vydanie: všetky práva vyhradené, dostupné pod komerčnou licenciou, vyrobené v Holandsku a určené pre organizácie, ktoré potrebujú podporovanú cestu grafu, nie iba zverejnenú. Ak stránka hovorí Rust 2021, grafové IR, vlastný JIT, žiadny LLVM, CPU/GPU/FPGA/WASM, sledovanie efektov, vlastníctvo naprieč pamäťovými priestormi, schopnostná bezpečnosť, distribuované vykonávanie, vkladanie C a Pythonu, pracovné postupy CLI, podpora editora a nástroje LSP, nie sú to dekoratívne vnútornosti. Sú to záväzky, ktoré musia prežiť hodnotenie reálnymi pracovnými záťažami.
List schopností je v tomto ohľade opatrný. Opisuje dizajnové ciele a hovorí, aby ste overili proti svojej pracovnej záťaži. Táto zdržanlivosť je dôležitá. Je oveľa zdravšia ako predstierať, že každé benchmarkové číslo sa prenáša. Systém by mal tímom poskytnúť spôsob, ako merať, kontrolovať a porovnávať vo vlastnom prostredí, nie žiadať ich, aby prijali univerzálny príbeh o rýchlosti.
Niekto musí vlastniť túto cestu, pretože každý cieľ sa snaží urobiť zdroj menej univerzálnym. Kera je miestom, kde sa tieto rozdiely medzi cieľmi stávajú explicitnou kompilátorovou prácou namiesto folklóru odovzdávaného po nahlásení chyby.
Deň, keď sa graf stane zmluvou
Predstavte si pôvodné hlásenie o chybe znova, ale s Kerou už v pracovnom postupe. Finančný tím schváli výpočet rizika. Odtlačok grafu sa zaznamená. Prvé nasadenie beží na CPU. Neskôr sa pre analýzu portfólia zavedie cesta GPU. Ešte neskôr sa pre cenotvorbu s nižšou latenciou použije cesta FPGA. Otázkou na každom kroku nie je, či nový hardvér znie pôsobivo. Otázkou je, či sa znižuje rovnaký graf a či sémantika cieľa zachováva identický výsledok.
Konverzácia sa mení. Tím platformy môže hovoriť o plánovaní a nákladoch. Tím kompilátora môže hovoriť o backendoch. Tím zhody môže hovoriť o odtlačku. Vlastník podniku sa môže opýtať, či je presun hardvéru prevádzkové rozhodnutie alebo prepísanie. Produkt dáva všetkým jeden objekt, na ktorý môžu ukazovať.
To je tichá hodnota IR s adresovaním podľa obsahu. Premieňa spúšťanie naprieč platformami zo série presvedčivých vysvetlení na záznam. Robí z grafu potvrdenku. Umožňuje, aby rovnaký .keg napájal každý backend. Dáva organizácii základ, ktorý patrí výpočtu, nie jedinému stroju.
Žiadny kompilátor nemôže odstrániť potrebu inžinierskeho úsudku. Tímy stále musia starostlivo vyberať ciele, poctivo testovať pracovné zaťaženia, rozumieť limitom cieľov a rozhodnúť, ktoré domény vyžadujú bitovú zhodu. Kera však môže tieto rozhodnutia spraviť explicitnými. Môže zabrániť tomu, aby sa migrácia výkonu náhodou stala sémantickou migráciou.
Ponaučenie o loweringu
Kera je dôležitá, pretože ťažká časť nie je mať dômyselný nápad na lowering. Ťažká časť je preniesť ten nápad cez všetky nudné miesta, kde sa inžinierstvo buď stáva dôveryhodným, alebo sa mení na folklór: diagnostika, zelené stromy, hash typov, kontrola požičiavania, optimalizácia s pevným bodom, validácia invariantov, serializácia .keg, emisia backendu, bezpečnostná politika, audítorské denníky, podpora editorov a spúšťanie špecifické pre cieľ.
Lowering je práca, pretože každý cieľ sa snaží urobiť zdroj menej univerzálnym. Deterministické inžinierstvo kompilátorov je disciplína odmietania nechať to stať sa ticho. CPU chce vektory. GPU chce jadrá. FPGA chce cykly. WASM chce obmedzenia. Organizácia chce jednu odpoveď. Úlohou Kery je zachovať význam výpočtu a zároveň nechať každý cieľ robiť to, v čom je dobrý.
To je inžiniersky tvar, nie papierová abstrakcia. Má kupujúceho, spôsob zlyhania, formát súboru, cestu kompilátora a prevádzkové dôsledky. Sľub nie je, že hardvér sa stane jednoduchým. Sľub je, že komplexnosť je reprezentovaná, znížená, skontrolovaná a vlastnená.
Keď príde ďalšie takmer správne číslo, tím by nemal musieť začínať folklórom o tom, ktorý stroj čo spustil. Mal by začať grafom. Zhodoval sa odtlačok? Ktorý backend emitoval kód? Ktoré schopnosti boli udelené? Ktorá sémantika cieľa sa použila? Ktorý artefakt bol uložený? To sú produktové otázky. Kera existuje, pretože sú to aj otázky kompilátora.