Smide och sök som bevisar sitt värde
The old trick problem
Every serious software system has a few pieces of code that matter far more than their size suggests. A loop that runs millions of times. A bit operation in a compression path. A small matrix routine. A modular arithmetic kernel. The sort of thing that looks harmless in code review and then quietly decides the energy bill, the latency budget, or the number of machines you need to buy. Very democratic, software. One tiny function can ruin the meeting for everyone.
Historically, those kernels are improved by people. A senior engineer remembers a trick from a paper. Someone digs through an old forum post. A benchmark suite is written. A few candidates are tried. The fastest one wins if it still appears correct. Then the organization freezes it, because touching it again feels like poking a sleeping transformer with a fork.
Forge is research into a better version of that process. It is a program synthesis engine for small, critical implementations: give it a typed specificationand properties, let it search candidate programs, measure and compare tradeoffs, verify equivalence, then lower the discovered implementation to targets that matter. The important word is not search. The important word is still. It still has to be correct.
This is why Forge lives in research. It is not a public product button where someone types make faster and receives a miracle. It is a synthesis workbench for partner experiments, kernel discovery, and research on how far automated search can go when it is tied to verification instead of benchmark theatre.
A specification is the starting line
Optimization without a specification is just gambling with nicer variable names. The moment a clever candidate appears, the team needs to know what it is meant to preserve. Does it handle every input or only the friendly ones from the benchmark? Does itrespect overflow behaviour? Is the algebraic identity valid under the representation actually used? Does it keep the same semantics when lowered to a different backend?
Forge starts from typed expressions and properties because the search needs a boundary. The boundary says what counts as equivalent. Without it, the engine can find something astonishingly fast by deleting half the work. Computers are excellent at malicious compliance when the contract is vague.
The search side is deliberately plural. Enumerative search is useful when the space is small enough to cover. CEGIS is useful when counterexamples can guide refinement. Genetic programming and MCTS explore differently. ML-guided search can learn cost models and prioritize promising regions. None of these is universally best. That is not a weakness. It is how search behaves in the real world. If one hammer solved every kernel, toolboxes would be very boring and hardware vendors would be unemployed.
The research question is how to combine those engines with enough proof pressure that the result is not merely clever. A synthesized kernel has to survive both the happy-path benchmark and the unhappy-path verifier. Otherwise the improvement is not engineering. It is a magic trick with a maintenance cost.
The verifier is the adult in the room
Forge använder en verifieringsstack eftersom ingen enskild kontroll räcker för alla domäner. Snabba exempel är billiga och användbara. Egenskapsbaserade tester hittar breda klasser av fel och förminskar motexempel till något en människa kan läsa. SMT-lösare som Z3 och CVC5 kan bevisa ekvivalens där kodningen är hanterbar. Utömmande kontroll är praktiskt för små domäner. E-graf-ekvivalensmättnad ger ytterligare en väg genom algebraisk ekvivalens.
Stapeln spelar roll eftersom kärnor misslyckas på irriterande sätt. En kandidat kan klara alla vanliga riktmärken och ändå vara fel på en gränsfall. Den kan vara korrekt för osignerade indata och fel för signerade. Den kan vara korrekt i ett matematiskt fält och fel efter att den valda representationen svämmar över. Den kan vara korrekt före sänkning och subtilt fel efter ett instruktionsvalsbeslut. Verifieraren finns för att optimism inte är en teststrategi. Vi kontrollerade. Upprepade gånger. Det förblir sant.
Det finns också en praktisk anledning att behålla flera bevisvägar. Formella metoder är kraftfulla, men de är inte gratis. Vissa kodningar tar timeout. Vissa domäner är för stora för utömmande kontroll. Vissa egenskaper är lättare att testa probabilistiskt först och bevisa senare. Forge behandlar verifiering som en tratt, inte en renhetsritual. Billiga kontroller avvisar uppenbart nonsens. Starkare kontroller skyddar den slutliga kandidaten.
Snabb är inte ett tal
Prestandaarbete blir löjligt när en enda mätning får dominera varje samtal. Latens spelar roll. Antalet operationer spelar roll. Minnesanvändning spelar roll. Registertryck spelar roll. Kompileringstid spelar ibland roll. Portabilitet spelar roll när samma kärna måste leva på mer än en backend. En kandidat som vinner på latens genom att bränna register som en liten brasa kan vara fel för det faktiska målet. En kandidat som är liten men långsam kan vara användbar någon annanstans. Kontexten förblir obesegrad.
Forge ramar därför in optimering som ett Pareto-problem. Motorn kan söka över mål snarare än att låtsas att det finns en universell poäng som levereras av ett mycket självsäkert kalkylblad. Det användbara resultatet är inte alltid den snabbaste kandidaten. Ibland är det en familj av kandidater med synliga avvägningar, så att en ingenjör kan välja den som passar driftsbegränsningen.
Detta är också varför jag inte gillar nakna hastighetsökningar i blogginlägg. Forskningssidan kan beskriva interna förväntningar och experimentella mål, men offentliga påståenden kräver färska körningar, aktuell hårdvara, aktuella kompilatorflaggor och exakt arbetsbelastningskontext. Annars blir talet en souvenir. Souvenirer är trevliga. De är inte arkitektur.
Det ärliga påståendet är starkare ändå: Forge handlar om att göra sökningen reproducerbar, jämförbar och kontrollerbar. När en kandidat vinner bör vi veta vilket mål den vann, vilka kandidater den slog, vilken verifierare som accepterade den och vilken backend den riktar sig mot. Det är mycket mer användbart än ett tal som flyter genom en presentationsdäck och ser dyr ut.
Sänkning är där bevis sätts på prov
En upptäckt implementation är bara användbar om den överlever resan till riktiga mål. Forge-forskningen omfattar sänkning till backendar som x86-64, RISC-V, WASM, Vulkan GPU-vägar, C och Verilog. Den mål listan är inte dekoration. Varje backend har sina egna begränsningar, instruktionsformer, minnesbeteende och felscenarier. Samma specifikation måste behålla sin innebörd medan implementationen blir något som målet faktiskt kan köra.
Det är här syntes kopplas till resten av Dweve-stacken. Core vill ha effektiva inre loopar. Numerus bryr sig om deterministiska numeriska kärnor. BitWeave vill ha binära vektor- och matrisoperationer som inte slösar på processorn. Kera bryr sig om att sänka beräkningsgrafer till riktig hårdvara. Forge kan mata dessa lager bara om den genererade implementationen är mer än snabb. Den måste vara ekvivalent, tillräckligt portabel för det valda målet och inspekterbar när något förändras.
Vad detta innebär för team
För ett team är den intressanta förändringen inte att en maskin kan upptäcka en snabbare kärna. Det är att kärnarbete blir mindre beroende av folklore. Istället för att en expert kommer ihåg rätt knep blir processen: ange kontraktet, sök i utrymmet, mät kandidater, bevisa ekvivalens, dokumentera avvägningen och generera målkod. Människor bestämmer fortfarande. De slutar bara göra all upptäckt för hand.
Det är viktigt för drift eftersom prestandaskuld är dyr på ett sätt som organisationer ofta döljer. En långsam kärna blir fler servrar. Fler servrar blir mer kostnad, mer energi, mer driftskomplexitet och mer brus i planeringen. En felaktig optimering blir incidenter. Ett korrekt men odokumenterat knep blir en framtida migreringsrisk. Forge är forskning för att minska den högen av undvikbart nonsens.
Det finns också en kulturell förändring. Manuellt prestandaarbete belönar ofta hjältedåd. Någon försvinner in i grottan och återvänder med ett smart bit-trick. Alla applåderar, ingen förstår det fullt ut, och företaget har fått en liten helig artefakt. Forge driver processen mot bevis: här är specen, här är sökvägen, här är de avvisade kandidaterna, här är verifieraren, här är den valda backend. Mindre mytologi. Mer kvitton.
Där arbetet fortfarande är svårt
Inget av detta gör syntes enkel. Specifikationer är svåra. Om specen är fel kan motorn troget upptäcka fel sak. Sökutrymmen kan explodera. Lösare kan ta timeout. Kostnadsmodeller kan vilseleda. Backend kan exponera detaljer som det abstrakta uttrycket inte brydde sig om. Verifiering kan vara stark i en domän och besvärlig i en annan. Den som säljer programsyntes som en varuautomat för optimal kod hoppar antingen över de svåra delarna eller tar extra betalt för besvikelse.
Forge är intressant just för att den möter dessa svåra delar direkt. Den kombinerar flera sökstrategier. Den håller verifieringen nära. Den behandlar mål som avvägningar. Den riktar sig mot riktiga backendar. Det förblir ett forskningsprogram eftersom vi fortfarande lär oss var gränsen går mellan automatiserad upptäckt, mänskligt omdöme, lösarbegränsningar och verklighetsanpassning i driftsättning.
Den gränsen är värd att utforska. Programvaruindustrin har för många små heta loopar, för mycket duplicerad prestandafolklore och för många optimeringar som ingen vill röra igen. Om Forge kan omvandla även en del av det arbetet till en repeterbar bevisprocess blir resultatet inte bara snabbare kod. Det blir lugnare kod. Lugnare kod är underskattad, mest av dem som inte har blivit väckta klockan 02:17.
Vad en bra Forge-körning kräver
Ett seriöst Forge-experiment börjar innan motorn körs. Teamet måste ta med sig en riktig kärna, inte ett vagt klagomål om prestanda. Det behövs representativa indata, kända gränsfall, målhårdvara, aktuella riktmärken och affärsskälet till varför den här kärnan är viktig. Annars kan syntesmotorn lägga mycket tid på att lösa ett problem som ingen egentligen har. Forskningsverktyg är inte immuna mot skräpindata. De gör bara skräpet dyrare att inspektera.
Den mest användbara indatan är ett litet, skarpt kontrakt. Vad ska funktionen beräkna? Vilka algebraiska lagar spelar roll? Vilket spillbeteende är avsiktligt? Vilka intervall är omöjliga per konstruktion, och vilka inträffade bara inte i den senaste testkörningen? Vilka utdata tål approximation, och vilka gör det inte? Ett team som inte kan svara på de frågorna har förmodligen inte ett optimeringsproblem ännu. Det har ett produktförtydligandeproblem som bär en kompilatorhatt.
En bra körning kräver också en målhållning. x86-64 och RISC-V är inte samma sak. WASM har andra begränsningar. Vulkan-GPU-vägar bryr sig om former och minnesrörelser. Verilog väcker hårdvarufrågor som vanliga applikationsteam sällan uppskattar före kaffet. Forge kan utforska sänkning mot mål, men det kan inte bestämma organisatoriska prioriteringar. Om portabilitet väger tyngre än hastighet på ett mål, säg det. Om latens slår minne, säg det. Om registertryck är den praktiska gränsen, säg det också. Motorn är kraftfull, inte synsk.
Utdata bör behandlas som ett bevispaket. Kandidat, mål, bevisväg, avvisade motexempel, backend, riktmärkeskontext och öppna reservationer. Det paketet är vad som låter människor fatta ett förnuftigt beslut. Ibland är det vinnande draget att anta kandidaten. Ibland är det att behålla den gamla kärnan för att portabilitetsavvägningen inte är värd det. Ibland är upptäckten att specen var för lös. Alla tre utfallen är användbara. Bara ett av dem ser spännande ut i en demo, vilket är varför demos är ett dåligt substitut för ingenjörskonst.
Lärdomen
Lärdomen från Forge är enkel: prestanda ska inte springa om bevis. Sökning är kraftfull, men en sökmotor utan verifiering är bara ett mycket energiskt sätt att skapa buggar. Verifiering är kraftfull, men utan sökning väntar den på att människor ska komma med kandidater. Forge för samman de två och frågar vilka kärnor vi kan upptäcka när maskinen får utforska, men inte får ljuga.
Det är den forskning som är värd att göra. Typade specifikationer, kandidatsökning, bevisstrutar, Pareto-mål och backend-sänkning. Inte magi. Inte en produkts genväg. Ett sätt att skapa bättre liten kod med bevis bifogade.