Software muss nicht mehr langsam sein

Ich arbeite an einem ähnlichen agentisch entwickelten Regex-Projekt namens SafeRE:

https://github.com/eaftan/safere

https://eaftan.github.io/safere-intro/

Meins ist für Java und soll produktionsreif sein. Das erste Ziel ist es, lineares Zeitverhalten zu garantieren, um ReDoS-Angriffe zu verhindern. Mein Mitarbeiter und ich haben es kürzlich optimiert, um natives RE2 in der Leistung zu übertreffen.

Es stellt sich heraus, dass Optimierungen unglaublich gut für eine agentische Schleife geeignet sind. Du hast konkrete Abnahmekriterien (muss eine deutliche Verbesserung bei einem Benchmark-Fall zeigen, muss Tests bestehen). Der Agent ist wirklich, wirklich gut im Umgang mit Werkzeugen wie Profiler und Disassembler, besser als ich (und ich mache das seit 20 Jahren). Es überbrückt auch Dinge, deren Erlernen bei mir eine Weile dauern würde, wie die Funktionsweise der in der Entwicklung befindlichen Vector (SIMD) API in Java. Ich verstehe das Konzept, aber es würde eine Weile dauern, bis ich Javas Implementierung verstehe. Der Agent kann einfach die Doku lesen und loslegen.

Der Schlüssel ist die Erstellung einer guten Benchmark-Suite und die Sicherstellung, dass der Agent keine Optimierungen liefert, die zu eng oder zu sehr auf die Benchmark-Fälle fokussiert sind. Du brauchst auch eine wirklich starke Testsuite, um sicherzustellen, dass du keine Korrektheitsregressionen einführst. SafeRE hat Milliarden von Tests; eine Teilmenge von mehreren Millionen läuft in CI, die anderen werden auf Abruf ausgeführt.

Hier ist das auf den Punkt gebracht:

> Ein stochastischer Suchprozess mit einem ausführbaren Optimierungsziel über den Raum der Programme S kann das Ziel nur erhalten oder verbessern

Das ist Superoptimierung. Das wissen wir seit den 80ern (Massalin, STOKE ist neuer: https://github.com/StanfordPL/stoke). Die einzige Neuheit ist, dass der Vorschlagende jetzt mit LLMs viel besser ist.

Darüber hinaus gibt es eine große Anzahl von Gründen, warum von Agenten geschriebene Software langsam ist:

- LLMs machen Daten- oder hardwareorientiertes Design immer noch nicht gut out of the box, und wenn du ernsthafte neuartige Arbeit leistest, über das Portieren eines extrem gut verstandenen Programms mit extrem gut verstandenen Arbeitslasten hinaus, wirst du Stunden damit verbringen, schlechte Allokationsentscheidungen aufzuspüren (vgl. warum TigerBeetle keine Agenten verwendet), die oft die Wurzel des Übels sind (bevor du zu etwas Weiterem greifen würdest)

- Die Stellschrauben, die du für ernsthafte Leistung bräuchtest, sind in Sprachen, in denen LLMs gut sind, fast unerreichbar (selbst Rust erfordert eine Disziplin, die die Standardsprache nicht durchsetzt). Wenn du in die niedrigeren Ebenen abtauchst, tauschst du Kontext gegen Zugang zu diesen Hebeln. Die Hebel sind auch "weich": Du findest dich dabei, eine Reihe von Fähigkeiten und Werkzeugen zu schreiben, um die Disziplin durchzusetzen.

Die Realität ist, um performanten Code (schnell) aus einem Agenten herauszubekommen, musst du wissen, wie man performanten Code schreibt (und du musst wissen, wie man die Informationen an die Oberfläche bringt, die du verwenden würdest, um einen Verifizierer für so etwas zu erstellen, an die [...]

"LLMs verursachen langsamen, aufgeblähten Code – die werden sich noch wundern, wenn sie alles in superoptimiertem Assembler neu schreiben."

Diese Person versteht nicht, wie man effizienten Code schreibt. Ich kann in fast jeder Sprache (mit ein paar Ausnahmen) Code schreiben, der "superoptimierten Assembler" übertrifft. Effizienten Code zu schreiben, hängt nicht von der Sprache ab und oft auch nicht von den besten Algorithmen (aber manchmal schon). Es geht darum, Speicher- und Cache-Nutzung zu optimieren. Und das ist orthogonal zu dem, worüber der Autor schreibt. Außerdem sind LLMs schrecklich darin, die Speichernutzung zu optimieren. Es gibt einfach zu wenig Trainingscode, der das gut macht, und viel zu viel, der das nicht tut.

Als Beweis kann ich das Web buchstäblich langsamer werden spüren, und ich wette, viele andere spüren das auch.

ChatGPT MacOSX ist die einzige Software, die auf meinem Rechner regelmäßig abstürzt, wenn ihr Speicherverbrauch ohne ersichtlichen Grund auf etwa 50 GB ansteigt.

Und diese Software wurde von einigen der bestbezahlten Softwareentwickler der Welt gebaut, mit vollem Zugriff auf die gesamte LLM-Rechenleistung der Welt.

Ich benutze Computer seit 4 Jahrzehnten. Sie sind nicht schneller geworden. Das Kernkraftwerkscomputersystem, das wir 1989 gebaut haben, musste ausgewählte Bildschirme in 1 Sekunde anzeigen. Ich glaube nicht, dass irgendeine App, die ich heute benutze, das schafft.

Für mich war der Vergleich schon immer 3DsMax vs. Blender. Gleiche Art von Software, gleiche Funktionen, aber Blender ist so viel schneller.

Architektonische Entscheidungen waren schon immer wichtig.

Ich verstehe jetzt, dass der meiste Software langsam ist, weil sie aus Gründen der gemeinsamen Nutzung Ressourcen kontrollieren muss oder einfach weil sie sicher vor Konkurrenz geschützt ist. Z.B. ist GitHub ersteres: Du kannst dir selbst einen Git-Host und ein CI/CD-System geben, das viel höhere Qualität hat, da du wahrscheinlich seine sozialen Funktionen nicht nutzt. Ich denke, Dinge wie Apples Fünf-Finger-nach-innen-Geste sind letzteres. Früher konnte man es tun und sofort tippen, aber heutzutage muss es die Animation usw. rendern, bevor Tastatureingaben registriert werden. Diese Software ist langsam, weil du sie in macOS nicht ersetzen kannst.

Aber all diese Dinge werden sich mit der Zeit ändern. Die Hölle, das ist die Software anderer Leute.