Er is geen reden meer dat software traag is

In reactie op een reactie op mijn vorige post, waarin werd gesteld dat de kosten voor voorheen gespecialiseerd prestatiewerk met meerdere grootteordes zijn gedaald, en dat werk dat vroeger een persoon of team met een zeldzame set vaardigheden vereiste nu kan worden gedaan door iedereen die een paar zinnen kan typen, reageerde Marc Brooker als volgt:

"Ik ben het volledig eens met je slotpunt. Dynamische, aangepaste software, afgestemd op een specifieke werklast in plaats van een klasse van werklasten, lijkt een zeer waarschijnlijke uitkomst. (Wat gepaard gaat met allerlei eigen risico's en kansen). Het doet me een beetje denken aan FFTW. En een heleboel vreemde oude demoscene-technieken die erop gericht waren superfast en klein te zijn voor een zeer specifiek probleem (en vaak zeer specifieke hardware). Ik herinner me bijvoorbeeld een demo die zijn eigen code als texturen hergebruikte om een geweldige cache-locality te krijgen."

En Michael Malis merkte op:

"Er gaat een meme rond dat AI niet helpt omdat 'code nooit het moeilijke deel was.' Ik denk dat dat waar is in sommige domeinen, maar in andere was het schrijven van de code absoluut het moeilijke deel. JIT-compilers zijn daar een geweldig voorbeeld van. Voor veel software zou een JIT-compiler enorm helpen bij het versnellen van de code. De zeldzaamheid van JIT-compilers doet me geloven dat het implementeren ervan historisch gezien te moeilijk was om rendabel te zijn. LLM's hebben de drempel verlaagd en het veel gemakkelijker gemaakt om een JIT-compiler te schrijven. Dit is de these achter pgrust. Databases waren historisch gezien de moeilijkste software om te bouwen en waren daardoor beperkt. Nu, met AI, kunnen we ambitieuzer zijn over het type software dat we bouwen."

Optimaliseren voor een klasse van werklasten

Laten we dit testen met FRE, de regex-engine die we in het vorige bericht hebben gebouwd. Ter herinnering: deze is gemaakt door een agent een maand lang in een loop te laten draaien om de prestaties van de regex-engine te verbeteren, met toegang tot de rebar regex benchmark suite. Dit resulteerde ertoe dat FRE zwaar overfit was op rebar, totdat we onze agent waarschuwden dat we een holdout benchmark hadden. Dit zorgde ervoor dat de agent de optimalisaties genoeg generaliseerde zodat de prestaties acceptabel waren op onze holdout.

Er is geen specifieke reden om een "software factory" regex-engine te gebruiken die een goed geteste regex-engine op holdout-benchmarks niet verslaat, maar één opvallend ding aan FRE was dat de native AOT-gecompileerde versie erg goed presteerde bij langere zoekopdrachten. Het is dan ook logisch dat men de native code-compiler in een andere thread zou kunnen draaien terwijl ripgrep zijn normale matcher uitvoert, om vervolgens over te schakelen naar de native code zodra de compilatie is voltooid. Dit resulteert over het algemeen in slechtere prestaties voor korte queries, omdat we een thread verliezen aan compilatie, maar ik hecht veel meer waarde aan de tijd die ripgrep kost wanneer hij vele seconden of minuten draait dan wanneer hij enkele seconden draait.

Op dezelfde manier als dat we een regex-engine in een paar minuten menselijke tijd kunnen bouwen, kunnen we dit experiment ook in een paar minuten menselijke tijd uitproberen. Ik typte een paar zinnen en een agent deed het werk om dit mogelijk te maken (wat voor een mens een aanzienlijk stuk code-chirurgie zou zijn) en voerde de benchmark uit op werkelijke ripgrep-queries uit mijn codex-geschiedenis.

Voor langere queries zien we hier een prestatieverbetering van 2x-4x voor een paar zeer eenvoudige queries. De meeste queries zijn echter complexer, en wanneer we runnen op representatieve holdout-queries waar AOT ingeschakeld zou moeten zijn, krijgen we een versnelling van ongeveer 7%. Geen aardverschuivend resultaat, maar ook geen slecht resultaat voor een paar minuten typen naar codex (en het doet nog steeds meer optimalisaties en zal presumptief de zaken verder versnellen).

Het is echter belangrijk op te merken dat, zelfs met de tijd om de compiler te draaien, er veel gevallen zijn waarin de native code-gecompileerde versie trager is dan de Rust regex crate. Dit gebeurt vooral bij complexere queries waarbij de Rust regex crate een algoritmische optimalisatie heeft en de FRE native code-compiler terugvalt op iets naïfs (de agent die FRE creëerde, besteedde namelijk veel minder tijd aan de native code-compiler dan aan de "normale" regex-engine).

Een index bouwen?

Dit is misschien wel een onzinnige actie, want als we herhaaldelijk naar tekst zoeken op een computer, is de voor de hand liggende manier om dat te versnellen niet het schrijven van een native code-compiler voor regex-matching, maar het maken van een index. Maar het punt hier is simpelweg dat dit soort technisch werk, dat vroeger veel tijd en expertise kostte, nu triviaal kan worden gedaan.

Als we een tekstindex zouden willen bouwen, komt het goed uit dat ik heb gewerkt aan BitFunnel, de Bing-zoekindex die gespecialiseerd was in constante/snelle tekstingestie en de Best Paper Award won bij SIGIR. Ik kan dus aan een paar experimenten denken om een snelle lokale index van de hele machine te bouwen (de projecten die ik heb gezien lijken bedoeld om je code-directories te indexeren, maar wat mijn machineprestaties echt hindert is wanneer codex besluit ripgrep uit te voeren tegen enorme tijdelijke directories met een ton gegenereerde bestanden).

Als ik bij een AI-lab zou werken en toegang had tot SOTA-modellen die draaien op Cerebras-chips of andere accelerators, zou ik bestaande indexers onderzoeken om te zien of ze snel genoeg zijn of dat ik iets op maat wil bouwen. Terwijl de open-source versie van BitFunnel "slechts" een bytecode-interpreter en één JIT bevat, bevat de Bing-versie meerdere JIT-compilers. Een project met dat niveau van optimalisatie was vroeger een enorme onderneming, maar "ik zou dat in een weekend kunnen doen" is nu daadwerkelijk waar voor sommige van dit soort projecten.

Optimalisaties zijn goedkoop

De drastische verlaging van de kosten voor optimalisaties is al zichtbaar sinds november 2025 en misschien zelfs eerder. Als voorbeeld uit de dagen van GPT-5.1 of 5.2: zonder kennis van game-AI's probeerde ik een Azul AI te bouwen. Dit bleek met een aanzienlijke marge de sterkste AI ter wereld voor dat spel te zijn. Uit de thesis die de op één na sterkste AI beschrijft, denk ik dat mijn AI waarschijnlijk iets beter is aan de "AI-kant", maar de belangrijkste plek waar hij wint, is bij de optimalisatie.

Bijvoorbeeld: die andere AI is single-threaded en mijn AI is multi-threaded. Omdat ik zowel een native code-versie als een wasm shared memory + javascript versie heb, en twee verschillende zoekarchitecturen die volledig verschillende multi-threading algoritmen vereisen (minimax voor een zeer klein en snel net en MCTS voor een groter net), zou dit een enorme onderneming zijn geweest als het handmatig was gedaan.

Er is een reeks standaardzaken die zinvol zijn om een multithreading-algoritme te debuggen en te verifiëren, zoals het implementeren van replay vanuit debug-logs die bugs kunnen reproduceren, ondanks dat het algoritme non-deterministisch is. Alleen dat zou waarschijnlijk dagen tot een week werk hebben gekost als ik het met de hand had gedaan, maar het is precies het soort ding dat een agent triviaal in een loop kan doen. Veel van de monotonie die vroeger nodig was om een lastige optimalisatie als deze werkend te krijgen, is verdwenen.

Dit geldt ook voor veel andere lastige optimalisaties. Uit mijn ervaring met het schrijven van CPU-microcode, CPU-verificatie en het optimaliseren van een zoekmachine-index, heb ik vaak naar optimalisaties gekeken en gedacht: "Hmm, dit zou de prestaties met 2% verhogen, maar het kost N persoonsdagen om te verifiëren dat deze lastige optimalisatie werkt." Ik maakte dan een afweging op basis van of het de tijd waard was. Nu die N met een enorme factor is gedaald (vaak 1000x of meer in menselijke tijd), stijgt het aantal optimalisaties dat zinvol is om uit te voeren enorm.

In het geval van de game-AI lijkt het erop dat je ongeveer 100 Elo wint voor elke verdubbeling in snelheid. Alleen het toevoegen van multithreading is al genoeg om een verder vergelijkbare AI weg te vagen op een grote machine. Als je daar 10-20 meer optimalisaties bij stapelt die voor de meeste mensen te vervelend zijn om handmatig te doen, is het verschil in kracht enorm. Het is dan niet meer redelijk om te proberen bij te blijven met een handgeschreven AI.

Iemand met echte AI-expertise zou mijn AI waarschijnlijk kunnen verslaan op de "AI-kant", maar als het niveau van expertise enigszins vergelijkbaar is, zal de door LLM geschreven versie domineren voor elke gegeven hoeveelheid bestede tijd.

Een ander voorbeeld: als onderdeel van de voorbereiding op performance-interviews probeerde Jamie Brandon de inmiddels openbare performance-takehome van Anthropic. Na zijn poging liet hij Claude verder gaan waar hij was gebleven, en dat leverde een veel beter resultaat op. Veel van de optimalisaties waren dingen die hem wel waren occurred, maar waar hij nog niet aan toe was gekomen, en anderen waren "gekke dingen die ik nooit zou proberen, tenzij ik hier weken aan werkte."

Hoewel het misschien oneerlijk is om het resultaat van een agent te vergelijken die verdergaat waar hij bleef (omdat zijn werk een startpunt is), probeerde ik de taak vers aan een agent te geven en deze behaalde een zeer vergelijkbare score.

Werklast-specifieke optimalisatie

Het idee van dynamische, aangepaste software die is afgestemd op een specifieke werklast in plaats van een klasse van werklasten, lijkt onvermijdelijk. Michael Malis van pgrust zei iets soortgelijks:

"[discussie over pgrust optimalisaties] ... Ik denk dat het makkelijk genoeg is om deze optimalisaties te creëren dat we naar de werklast van een klant kunnen kijken en ze kunnen toevoegen waar nodig."

Vlak voordat ik dit bericht begon te schrijven, liet ik een agent een werklast-specifieke optimalisatie uitvoeren voor mijn ripgrep-queries. Dit kostte me ongeveer 2 minuten om op te starten. Na één ronde van optimalisatie is de werklast-geoptimaliseerde versie 2% sneller dan de standaard ripgrep op de holdout, en hij wordt nog steeds sneller. 2% is geen groot verschil voor mijn lokale ripgrep-gebruik, maar gezien het feit dat dit slechts minuten tijd kostte, zou ik deze winst accepteren.

In het algemenere geval is het voor bedrijven met meer schaal zinvol om met klanten samen te werken om programma's te piloteren die hun data gebruiken om zaken voor hen te optimaliseren.

***

Appendix: Er is geen reden meer dat software traag is

Ik ben het al lange tijd sterk oneens met het sentiment dat ontwikkelaars slecht zijn omdat ze trage code schrijven. Er zijn veel verschillende soorten programmeerexpertise en het is niet zo dat de meeste programmeurs geen expertise in prestaties hebben; het is waarschijnlijk dat het voor hen simpelweg geen zin heeft om die te ontwikkelen (gezien wat het bedrijf belangrijk vindt, de arbeidsmarkt, etc.).

Voor het voorbeeld hierboven: Jamie Brandon kreeg een aanbod van Anthropic en je kunt hem of iemand als hem waarschijnlijk alleen betalen als je OpenAI bent, maar je kunt wel een coding agent betalen die hem verslaat op een begrensd optimalisatieprobleem. De agent heeft niet zijn oordeel en zal slechter presteren op een open-ended probleem, maar dat is meer dan voldoende om redelijke prestaties te behalen bij allerlei problemen. Dit geldt niet alleen voor backend-prestaties, maar agents lijken ook niet slechter in front-end prestaties als je metrics zoals LCP en INP wilt verbeteren.

Appendix: Hoe draait codex ripgrep?

Hier is informatie over de distributie van ripgrep-queries op mijn machine. Ik beweer niet dat dit representatief is voor andere situaties.

• Patroonlengte: De distributie van de lengte van de gezochte patronen heeft veel meer lange patronen dan ik had verwacht. De p50 is 55 unicode-codepunten (tekens), en de p90 is 119!
• Complexiteit: Het aantal alternatieve armen in regexes is veel complexer dan wat ik handmatig doe.
• Tijd: De duur van de queries was korter dan verwacht, waarschijnlijk omdat enorme runaway-queries die minuten duren buiten mijn radar vallen.
• Opties: Codex wil vaak regelnummers en gebruikt zeer incidenteel PCRE2-regexes.
• Localiteit: Er is een lage localiteit voor welke patronen er worden gezocht (ongeveer 94% van de patronen kwam slechts één keer voor), maar een hoge localiteit in welke bestanden worden doorzocht.
• Type: 99% van de queries waren regex-queries (1% waren non-regex string-zoekopdrachten). 99,9% van de zoekopdrachten waren ASCII-only, maar ongeveer 55% van de doorzochte bestanden bevatten Unicode.

De werklast-specifieke optimalisaties waren hier vrij oppervlakkig omdat ik codex korte instructies gaf, maar met een gedetailleerder plan zouden meer gerichte optimalisaties voor veelvoorkomende use-cases grotere winsten kunnen opleveren.

Tot slot een reflectie op ROI: een tijd geleden verkleinde ik de paginagrootte in onze aanmeldingsflow van 50 MB naar 5 MB, en een revenue A/B-test wees uit dat dit de omzet met ongeveer 0,5% verhoogde. Ik ben een groot fan van het eerst pakken van de simpele en makkelijke winst; er zijn waarschijnlijk veel winsten met een hogere ROI dan het bouwen van custom compilers of ander zeer gespecialiseerd technisch werk.