Ingenieursphilosophie: John Carmack, Performance als moralisches Handwerk

Die wichtigsten Erkenntnisse

• Carmack behandelt Performance als moralische Frage, nicht als nachgelagerten Optimierungsschritt. Die Lücke zwischen Ihrem Code und der physikalischen Grenze der Hardware ist Verschwendung, und Verschwendung ist eine Entscheidung.
• Seine Methode ist subtraktiv: das Problem bis zum Fundament durchdringen, es auf den schnellen und einfachen Kern reduzieren und jede Funktion verweigern, die diesen Kern verlangsamt.
• Wenn sich das zugrunde liegende Problem ändert, schreibt er von Grund auf neu. Quake warf die Engine weg, die id berühmt gemacht hatte, weil echtes 3D ein anderes Problem war als dessen bloße Vortäuschung.
• Er arbeitete offen – tägliche .plan-Protokolle, später quelloffene Engines – aus einer einzigen Überzeugung heraus: Code, den Sie veröffentlichen werden, ist Code, den Sie ehrlicher schreiben.

Das Prinzip

„The speed of light sucks.” – John Carmack¹

Es ist ein Scherz, und es ist die gesamte Philosophie. Carmack sagte es über Netzwerklatenz – die harte physikalische Untergrenze dafür, wie schnell ein Paket einen Kontinent durchqueren kann – doch der Gedanke durchzieht jede Zeile, die er geschrieben hat. Die Maschine wird von der Physik regiert, und die Aufgabe des Ingenieurs besteht darin, so nah an die physikalische Grenze heranzukommen, wie das Problem es zulässt. Nicht nah genug. So nah, wie die Physik es erlaubt. Alles zwischen dem Benutzer und der Lichtgeschwindigkeit ist Verschwendung, und Verschwendung ist eine Entscheidung, die Sie getroffen haben.

Carmack behandelt Performance als moralische Frage und nicht als nachgelagerten Optimierungsschritt. Die meiste Software sammelt Langsamkeit an, wie ein Haus Gerümpel ansammelt – eine vernünftige Entscheidung nach der anderen, jede für sich vertretbar, die Summe unhaltbar. Carmacks Disziplin besteht darin, diese Anhäufung zu verweigern: das Problem bis zum Fundament durchdringen, es auf den schnellen und einfachen Kern reduzieren und genau das ausliefern. Dieselbe Überzeugung liegt dem Argument zugrunde, dass Performance keine Funktion ist, die man hinzufügt, sondern eine Eigenschaft, die man nicht verlieren darf – man optimiert kein langsames System zu einem schnellen; man baut ein schnelles und verteidigt es.

Und er legte seine Arbeit offen. Über mehr als ein Jahrzehnt veröffentlichte Carmack sein tägliches Ingenieursprotokoll – seine .plan-Datei – im offenen Internet, lesbar für jeden mit einem finger-Client.² Die schwierigsten 3D-Rendering-Probleme der 1990er Jahre wurden öffentlich gelöst, nahezu in Echtzeit. Das Arbeiten in der Öffentlichkeit war kein Marketing. Es war derselbe Instinkt wie der Code selbst: kein verborgener Zustand, nichts, was sich nicht prüfen lässt.

Kontext

John D. Carmack wurde am 21. August 1970 in Shawnee Mission, Kansas, geboren.³ Er besuchte zwei Semester lang die University of Missouri–Kansas City und brach dann ab, um seinen Lebensunterhalt mit dem Schreiben von Software zu verdienen. Es gab keine formale Lehre und keinen Abschluss. Er lernte Grafikprogrammierung so, wie es die Demoszene tat – indem er Hardware-Handbücher las, maß, was der Chip tatsächlich tat, und Assembler schrieb, bis die Zahlen stimmten.

Er landete bei Softdisk, einem Software- und Diskettenmagazin-Unternehmen in Shreveport, Louisiana, und arbeitete an einem Spiele-Abonnement namens Gamer’s Edge. Dort lernte er John Romero, Tom Hall und Adrian Carmack (nicht verwandt) kennen. Im September 1990 baute Carmack eine Demonstration, die auf einem PC nicht möglich sein sollte: flüssiges Seitwärtsscrollen in Konsolenqualität auf EGA-Hardware. Der IBM PC von 1990 zeichnete bei jedem Frame den gesamten Bildschirm neu – zu langsam für ein scrollendes Spiel. Carmacks Technik, das adaptive Tile-Refresh, nutzte obskure Funktionen der EGA-Hardware, um den bereits gezeichneten Bildschirm zu verschieben und nur die neu freigelegten Ränder neu zu zeichnen.⁴ Das Team baute den ersten Level von Nintendos Super Mario Bros. 3 als PC-Demo nach, um es zu beweisen. Nintendo lehnte ab. Das Team behielt die Engine.

Im Februar 1991 verließen sie Softdisk, um id Software zu gründen. Das Muster stand bereits fest: das Problem finden, das niemand gelöst hatte, es auf Hardware-Ebene lösen und das Produkt auf der Lösung aufbauen. Carmack sollte es erneut tun – mit texturmappiertem 3D, dann mit echtem polygonalem 3D, dann mit Virtual Reality. Das Umfeld um ihn herum – Michael Abrashs Graphics Programming Black Book, die zyklenzählende Kultur der Demoszene – behandelte den Prozessor als etwas, das man exakt verstehen und nicht bloß annähern sollte. Carmack machte diese Kultur berühmt.

Das Werk

Commander Keen und Doom: Der schnelle Kern (1990–1993)

Commander Keen in Invasion of the Vorticons (Dezember 1990) war das erste kommerzielle Spiel, das auf adaptivem Tile-Refresh aufbaute. Es zählte weniger als Spiel denn als Beweis: dass ein sorgfältiges Lesen der Hardware die Lücke zwischen einem Allzweck-PC und einer dedizierten Konsole schließen konnte. Das flüssige Scrollen war kein Grafiktrick, der obendrauf gesetzt wurde. Es war die Engine.

Doom (1993) ist das kanonische Beispiel für Carmacks Methode. Um seine Umgebungen auf einem PC von 1993 schnell genug zu rendern, übernahm er die binäre Raumpartitionierung – BSP-Bäume, formalisiert in einer akademischen Arbeit von 1980, die Carmack aufspürte und adaptierte – um die Reihenfolge vorzuberechnen, in der die Wände gezeichnet werden mussten, sodass die Engine niemals ein Pixel überzeichnete, das sie später ohnehin verdecken würde.⁵ Doom ist kein echtes 3D; es ist eine 2D-Karte, gerendert mit genug Raffinesse, um volumetrisch zu wirken. Genau diese Unterscheidung ist der Punkt. Carmack baute nicht das allgemeinste System. Er baute das System, das auf der existierenden Hardware schnell lief, und verweigerte jede Funktion, die die Kernschleife verlangsamt hätte. Der schnelle, einfache Kern, ausgeliefert.

Quake: Echtes 3D in Software (1996)

Quake (1996) war der Neuaufbau von Grund auf. Wo Doom Tiefe vortäuschte, renderte Quake echte dreidimensionale polygonale Welten – geneigte Flächen, Blicke nach oben und unten, echte Geometrie – in Software, bevor 3D-Beschleuniger für Endverbraucher verbreitet waren.⁶ Die Engine kombinierte vorberechnete BSP-Sichtbarkeit mit offline berechneten Lightmaps und handoptimiertem Assembler, um zu leisten, was die landläufige Meinung einer CPU jener Zeit nicht zutraute. id veröffentlichte später GLQuake, einen OpenGL-Renderer, der dazu beitrug, die 3D-Grafikkarte für Endverbraucher zu etablieren.

Quake ist das Werk, an dem Carmacks gesamte Haltung auf einmal sichtbar wird: Er warf die Engine weg, die das Unternehmen berühmt gemacht hatte, durchdrang das neue Problem (echtes 3D) bis zum Fundament und baute neu. Keine Wiederverwendung um ihrer selbst willen. Die vorherige Lösung war nicht heilig; das Problem war es.

Die offenen id-Engines und die .plan-Dateien (1997–2011)

Carmack tat zwei ungewöhnliche Dinge mit dem Code, der ihn reich machte. Er veröffentlichte sein tägliches Arbeitsprotokoll – die .plan-Dateien – sodass die Ingenieursarbeit lesbar war, während sie geschah.² Und dann verschenkte er die Engines. id machte die Doom-Engine 1997 quelloffen, Quake 1999, und veröffentlichte weiterhin den Quellcode jeder Generation von id Tech, sobald die nächste ausgeliefert wurde, über Doom 3 hinaus.⁷ Sein Argument war schlicht: Die Freigabe alten Codes lässt jüngere Entwickler lernen, wie das Ding tatsächlich gebaut wurde, und „freie Software, die Menschen schätzen, mehrt den Wohlstand der Welt.”⁸

Diese Bereitschaft ist der Teil, den die meisten performance-besessenen Ingenieure nie erreichen. Carmacks Handwerk war private Disziplin, öffentlich gemacht. Die Bereitschaft, gelesen zu werden – jedem zu erlauben, das tägliche Protokoll und schließlich den Quellcode zu prüfen – ist selbst ein Qualitätsversprechen. Code, den Sie veröffentlichen werden, ist Code, den Sie ehrlicher schreiben.

Oculus VR: Die Latenzgrenze (2013–2019)

Bei Oculus wurde Carmacks lebenslanger Feind – die Latenz – zum gesamten Problem. Er schrieb, dass „die Latenz zwischen der physischen Bewegung des Kopfes eines Benutzers und den aktualisierten Photonen eines am Kopf getragenen Displays, die seine Augen erreichen, einer der kritischsten Faktoren für ein hochwertiges Erlebnis ist”, und dass wahrnehmbare Kopf-Tracking-Latenz „außerdem eine der Hauptursachen für Simulatorübelkeit ist.”⁹ Er setzte ein Budget – das Ziel lag in der Größenordnung von 20 Millisekunden von der Bewegung bis zum Photon – und behandelte jede Stufe der Pipeline als einen Ort, an dem sich Mikrosekunden zurückgewinnen ließen. Seine Timewarp-Technik reprojiziert ein bereits gerendertes Bild im letzten Moment vor der Anzeige, um die Kopfbewegung aufzufangen, die während des Renderns geschah.⁹ Es ist abermals das adaptive Tile-Refresh, dreiundzwanzig Jahre später: nicht neu zeichnen, was sich wiederverwenden lässt, und das Ergebnis an der physikalischen Grenze messen.

Die Methode

Die Methode ist über dreißig Jahre und vier Problemfelder hinweg konsistent.

Das Problem bis zum Fundament durchdringen. Carmack liest das Hardware-Handbuch, misst das tatsächliche Verhalten und arbeitet aus ersten Prinzipien statt aus Konvention. BSP-Bäume, Lightmaps und Timewarp standen in keinem Lehrbuch; sie wurden aus dem abgeleitet, was das Problem tatsächlich verlangte.

Auf den schnellen, einfachen Kern reduzieren. Doom ist kein 3D, weil 3D nicht nötig war, um sich auf der Hardware von 1993 nach 3D anzufühlen. Die Disziplin ist subtraktiv: die innere Schleife identifizieren, sie schnell machen und die Funktionen verweigern, die sie verlangsamen würden.

Von Grund auf neu schreiben, wenn sich das Problem ändert. Quake erweiterte nicht die Doom-Engine. Carmack behandelt ein funktionierendes System als wegwerfbar in dem Moment, in dem sich das zugrunde liegende Problem verschoben hat. Versunkene Kosten sind kein Argument.

Tiefe, ununterbrochene Konzentration. Bei Carmacks Marathon-Programmiersitzungen ging es nie um Ausdauer um ihrer selbst willen. Eine ganze Engine im Arbeitsgedächtnis zu halten – das Datenlayout, die innere Schleife, die Grenzfälle alle auf einmal – braucht Stunden zum Laden und zerschellt in dem Augenblick, in dem man den Kontext wechselt. Er schützte diesen Zustand so, wie er die Zyklen in der Render-Schleife schützte: als die knappe Ressource, auf der die Arbeit tatsächlich lief.

Später: funktionaler Stil in C. Ab der Ära von Doom 3 und danach kam Carmack dazu, reine Funktionen zu bevorzugen und veränderlichen Zustand selbst in C und C++ zu minimieren – nicht aus Mode, sondern weil Code ohne verborgenen Zustand Code ist, dessen Verhalten man vorhersagen kann, was weniger Fehler bedeutet.¹⁰ Es ist derselbe Instinkt wie bei den .plan-Dateien: nichts, was sich nicht prüfen lässt.

Einflusskette

Wer ihn prägte

Michael Abrash kommt einem Mentor in dieser Linie am nächsten. Abrashs Schriften zur x86-Grafik – später gesammelt als das Graphics Programming Black Book – kodifizierten die zyklenzählende, alles-messende Kultur, die Carmack praktizierte. Die beiden arbeiteten später bei id zusammen und, viel später, bei Oculus, wo Abrash Chefwissenschaftler wurde. (Direkter Einfluss)

Die Demoszene und die Kultur der Assembler-Optimierung der späten 1980er Jahre lehrten die grundlegende Überzeugung: Der Prozessor ist exakt erkennbar, und die Lücke zwischen Ihrem Code und der Hardware-Obergrenze ist Ihre Verantwortung. (Prägender Einfluss)

John Romero, sein Partner bei id, war eher die Ergänzung als der Lehrer. Romeros Design- und Level-Arbeit gab Carmacks Engines etwas, das es wert war, ausgeführt zu werden. Die Partnerschaft ist die Erinnerung daran, dass ein schneller Kern notwendig, aber nicht hinreichend ist – die Engine existiert, um gespielt zu werden.

Wen er prägte

Die gesamte Spiele-Engine-Industrie. BSP-Sichtbarkeit, Lightmaps und das Quelloffenmachen reifer Engines wurden zur Grundpraxis. Eine Generation von Engine-Programmierern lernte 3D-Rendering, indem sie den id-Tech-Quellcode las, den Carmack freizugeben beschloss.

3D-Grafikhardware für Endverbraucher. Quakes OpenGL-Pfad war ein frühes kommerzielles Argument für die 3D-Beschleunigerkarte und half dabei, die GPU in den Mainstream-PC zu ziehen.

Moderne Virtual Reality. Timewarp und das unerbittliche Latenzbudget gehören heute zum Standardvokabular jeder VR-Pipeline. Das 20-Millisekunden-Ziel, dem Carmack nachjagte, ist der Grund, warum den Nutzern heutiger Headsets nicht übel wird.

Der rote Faden

Andrej Karpathy baut neuronale Netze von Grund auf neu, weil sich Verständnis nicht übertragen lässt – man muss es selbst herleiten. Carmack leitet seine Renderer auf dieselbe Weise her: nicht aus einem Framework, sondern aus der Hardware und dem Problem. Und während Linus Torvalds „guten Geschmack” schätzt – den Sonderfall, der sich in den allgemeinen Fall auflöst – schätzt Carmack die innere Schleife, die die geringste Arbeit verrichtet, die die Physik zulässt. Beide sind dieselbe Überzeugung in unterschiedlichem Gewand: Die richtige Struktur ist keine Verzierung auf dem Problem; sie ist das Problem, richtig gesehen. (Brücke der Serie)

Was ich daraus mitnehme

Die Lehre, die ich behalte, ist, dass Performance Ehrlichkeit ist. Ein langsames System ist meist eines, dessen Urheber das Problem nie gut genug verstanden hat, um seinen schnellen Kern zu finden – er fügte Abstraktionen zusammen, bis es funktionierte, und „funktionierte” war der Punkt, an dem er aufhörte. Carmack hört stattdessen an der physikalischen Grenze auf. Das ist derselbe Maßstab wie der, dass Qualität die einzige Variable ist: Die Frage lautet nie „Ist das schnell genug, um es auszuliefern?”, sondern „Verstehe ich tatsächlich, warum es so langsam ist?”

In der Welt, in der ich heute baue – Agenten, Tool-Schleifen, KI-Systeme – ist die Versuchung das Gegenteil von Carmacks Disziplin: Frameworks stapeln, Latenz mit mehr Modellaufrufen überdecken, nie lesen, was das System tatsächlich tut. Der Carmack-Zug besteht darin, die Schleife zu profilieren, den dominierenden Teil zu finden, ihn bis zum Fundament zu verstehen und den Rest wegzulassen. Diese Überzeugung – dass Geschmack ein technisches System ist, das man messen kann, und keine Stimmung, die man behauptet – ist der rote Faden von einem EGA-Scroll-Trick aus dem Jahr 1990 bis zu einem Agentensystem von 2026.

FAQ

Was ist John Carmacks Ingenieursphilosophie?

Carmack behandelt Performance als moralische Frage und nicht als Nebensache. Die Disziplin besteht darin, ein Problem bis zum Fundament zu durchdringen, es auf den schnellen und einfachen Kern zu reduzieren, die Funktionen zu verweigern, die diesen Kern verlangsamen, und von Grund auf neu zu schreiben, wenn sich das zugrunde liegende Problem ändert. Er verbindet dies mit dem Arbeiten in der Öffentlichkeit – der Veröffentlichung seines täglichen Ingenieursprotokolls und dem Quelloffenmachen reifer Engines – aus der Überzeugung heraus, dass Code, den man prüfen kann, ehrlicher geschriebener Code ist.²⁸

Was hat John Carmack gebaut?

Carmack war 1991 Mitbegründer von id Software und Leitprogrammierer bei Commander Keen (1990, adaptives Tile-Refresh), Wolfenstein 3D (1992), Doom (1993, BSP-basiertes Rendering) und Quake (1996, echtes 3D-Software-Rendering). Er machte die id-Tech-Engines über zwei Jahrzehnte hinweg quelloffen, war CTO von Oculus VR, wo er die Arbeit an der Latenz von der Bewegung bis zum Photon vorantrieb, und gründete später das KI-Unternehmen Keen Technologies.⁵⁶⁷⁹

Was ist adaptives Tile-Refresh?

Es ist die Technik, die Carmack 1990 ersann, um flüssiges Seitwärtsscrollen auf der EGA-Hardware des IBM PC zu erreichen, die sonst zu langsam war, weil sie bei jedem Frame den gesamten Bildschirm neu zeichnete. Adaptives Tile-Refresh verschiebt den bereits gezeichneten Bildschirm mithilfe von EGA-Hardwarefunktionen und zeichnet nur die neu freigelegten Tiles an den Rändern neu, wodurch der Aufwand pro Frame drastisch sinkt. Es machte Commander Keen möglich und begründete Carmacks Markenzeichen: das Nadelöhr auf Hardware-Ebene zu lösen.⁴

Warum veröffentlichte Carmack seine .plan-Dateien und machte seine Engines quelloffen?

Die .plan-Dateien waren ein tägliches Ingenieursprotokoll, ursprünglich über das finger-Protokoll lesbar, das ids Entwicklung nahezu in Echtzeit dokumentierte.² Carmack machte später jede Generation von id Tech quelloffen, sobald deren Nachfolger ausgeliefert war, mit dem Argument, dass die Freigabe alten Codes neueren Entwicklern hilft zu lernen, wie Spiele wirklich gebaut werden, und dass wertvolle freie Software „den Wohlstand der Welt mehrt.”⁸ Beide Praktiken spiegeln dasselbe Prinzip wider wie sein Code: kein verborgener Zustand, nichts, was sich nicht prüfen lässt.

Quellen