Vergleich des von Claude erzeugten C-Compilers mit GCC

 (harshanu.space)
14 Punkte von GN⁺ 2026-02-10 | 5 Kommentare | Auf WhatsApp teilen
  • CCC (Claude’s C Compiler), vollständig von Anthropic's Claude Opus 4.6 geschrieben, wurde mit der Behauptung veröffentlicht, den Linux-Kernel kompilieren zu können
  • Der eigenständige Compiler in Rust implementiert alle Komponenten vom Frontend bis zum Linker selbst, bleibt aber bei Leistung und Optimierungsqualität deutlich hinter GCC zurück
  • In Benchmarks mit SQLite und dem Linux-Kernel kompilierte CCC zwar alle C-Dateien fehlerfrei, doch der Build scheiterte in der Linker-Phase an über 40.000 Referenzfehlern
  • Die Ausführung von SQLite ist bis zu 158.000-mal langsamer, die Binärdatei ist mehr als dreimal so groß, und Optimierungsoptionen (-O2 usw.) haben keine Wirkung
  • Dass eine KI einen vollständigen C-Compiler erzeugt hat, ist technisch bedeutsam, doch Effizienz und Kompatibilität reichen für den praktischen Einsatz noch nicht aus

Überblick und Struktur von CCC

  • CCC ist ein von Anthropic mit Claude erstellter vollständig KI-geschriebener C-Compiler und unterstützt x86-64, i686, AArch64, RISC-V 64
    • In Rust geschrieben, mit SSA-basierter IR, Optimierer, Codegenerator, Assembler, Linker und Erzeugung von DWARF-Debuginformationen
  • Es wird die Rollen von Compiler, Assembler und Linker getrennt erklärt, wobei der Linker als am komplexesten und fehleranfälligsten beschrieben wird
  • Da der Linux-Kernel GCC-Erweiterungen und komplexe Linker-Skripte nutzt, ist er als früher Testfall ungeeignet; stattdessen wurde SQLite als zentraler Benchmark gewählt

Testumgebung und Methode

  • Vergleich von GCC 14.2.0 und CCC unter identischen Bedingungen auf zwei Debian-basierten VMs (6 vCPU, 16 GB RAM)
  • Verglichene Punkte: Kompilierzeit, Binärgröße, Ausführungsgeschwindigkeit, Speichernutzung, Stabilität
  • CCC delegiert über die gcc_m16-Funktion nur 16-Bit-Boot-Code an GCC und verarbeitet den Rest selbst
  • Der SQLite-Benchmark ist CPU-zentriert aufgebaut und führt 42 SQL-Operationen in 10 Schritten aus

Zusammenfassung der wichtigsten Ergebnisse

  • Linux-Kernel 6.9: CCC kompilierte alle 2.844 C-Dateien, scheiterte aber in der Linker-Phase an 40.784 undefined reference-Fehlern
    • Fehlerursache: fehlerhafte Relocations und Symbolerzeugung in den Abschnitten __jump_table und __ksymtab
  • SQLite-Kompilierung: CCC ist 1,3-mal langsamer als GCC, bei 2,7- bis 3-mal größerer Binärdatei und 5,9-mal höherem Speicherverbrauch
  • SQLite-Ausführungsleistung: 737-mal langsamer als GCC -O0 und 1.242-mal langsamer als GCC -O2
    • Einfache Abfragen sind 1- bis 7-mal langsamer, verschachtelte Schleifenabfragen bis zu 158.000-mal langsamer
  • Alle 5 Crash-Tests bestanden, die funktionale Korrektheit ist also gegeben

Ursachen des Leistungsabfalls

  • Übermäßiges Register-Spilling: Die meisten lokalen Variablen werden auf dem Stack gespeichert, was zu übermäßig vielen Speicherzugriffen führt
    • In der Funktion sqlite3VdbeExec werden über 100 Variablen über den Stack verarbeitet, wodurch sich die Codelänge verdreifacht
  • Optimierungsoptionen wirkungslos: Die Ergebnisse von -O0 und -O2 sind vollkommen identisch; alle 15 SSA-Passes laufen auf jeder Stufe gleich ab
  • Beschädigter Frame Pointer macht Debugging mit GDB unmöglich
  • Aufgeblähte Codegröße: Die SQLite-Binärdatei ist mit 4,27 MB 2,78-mal größer als bei GCC, was mehr Instruction-Cache-Misses verursacht
  • Keine Erzeugung einer Symboltabelle: Ohne interne Funktionssymbole ist Profiling nicht möglich

Stärken und Grenzen von CCC

  • Stärken
    • Kompiliert alle C-Dateien des Linux-Kernels fehlerfrei
    • Korrektheit und Stabilität der SQLite-Ergebnisse sind gegeben, keine Segmentation Faults
    • Unterstützung einer GCC-kompatiblen Kommandozeilenschnittstelle
  • Grenzen
    • Extremer Einbruch der Ausführungsgeschwindigkeit (bis zu 158.000-mal)
    • Linker-Inkompatibilität führt zum Fehlschlag des Kernel-Builds
    • Zu große Binärdateien und zu hoher Speicherverbrauch
    • Fehlende Optimierung und Debuginformationen, -O-Optionen ohne Wirkung
    • Auch die Kompiliergeschwindigkeit ist 25 % langsamer als bei GCC

Das „Hello World“-Problem

  • Kurz nach der Veröffentlichung trat das Problem „Hello world does not compile“ auf
    • In der Präprozessor-Phase scheiterte es daran, stddef.h und stdarg.h nicht zu finden
    • Das Thema sorgte auf GitHub mit über 288 Reaktionen und rund 200 Kommentaren für Aufmerksamkeit
    • Einige Nutzer bewerteten es als „eine Compiler-Aufgabe auf Bachelor-Niveau“

Fazit

  • CCC ist ein Beleg dafür, dass eine KI einen vollständigen C-Compiler erzeugen kann
    • Alle C-Dateien des Linux-Kernels werden fehlerfrei verarbeitet, und SQLite läuft funktional korrekt
  • Für den praktischen Einsatz ist CCC jedoch ungeeignet
    • Die Ausführungsleistung ist extrem schwach, und Linker-, Optimierungs- und Debugging-Funktionen sind unvollständig
  • Als Forschungsleistung ist es bedeutend, doch für produktive Compiler bleiben bestehende Werkzeuge wie GCC und Clang weiterhin unverzichtbar

Verwandte Beiträge

5 Kommentare

 
roxie 2026-02-10

Aha, hierher stammt also das Meme „Hello world does not compile“ lol
 
fantajeon 2026-02-13

Am Anfang erinnert die Stimmung ein wenig an Go.
 
chcv0313 2026-02-12

Wenn man es immer weiter in einer Schleife verbessern lässt, kommt dann nicht irgendwann ein noch besserer Compiler heraus?
 
t7vonn 2026-02-11

Es scheint, dass man der Sache zugutehalten muss, dass sie immerhin das Niveau einer Studienaufgabe im Grundstudium erreicht hat..
 
GN⁺ 2026-02-10
Hacker-News-Kommentare

  • Diese Debatte zeigt sehr gut die beiden gegensätzlichen Sichtweisen auf LLM-Coding-Agenten
    Die Befürworter sagen: „Erstaunlich, dass in nur wenigen Stunden ein funktionierender Compiler entstanden ist“, während die Gegenseite meint: „Wenn er nicht wirklich funktioniert, hat das keine Bedeutung.“
    Je komplexer die Codebasis, desto schwächer werden die Agenten, und auch gegenüber der ständig wiederholten Behauptung „Die nächste Generation wird das schon beheben“ gibt es viel Skepsis.
    Anthropic sagte, man habe den Linux-Kernel kompiliert, tatsächlich scheiterte das aber, und damit wird die Kluft zwischen überzogenen AI-Erwartungen und der Realität sichtbar.

    • Das erinnert an den jüngsten OCaml-„vibe coded“-Vorfall
      Tests zu bestehen und oberflächlich korrekt aussehende Ausgaben zu liefern ist etwas völlig anderes, als Code mit wartbarer Qualität zu haben.
    • Jedes Mal, wenn wieder die Logik kommt, dass „die nächste Modellgeneration alles beheben wird“, ist das frustrierend.
    • Vielleicht braucht es eine C2-Wiki-Seite zu „sufficiently smart LLM“.
    • Diese Debatte wirkt fast wie die Entwicklungsgeschichte von SpaceX
      Zuerst hieß es „kann nur kleine Funktionen schreiben“, dann „kann Linux nicht kompilieren“, dann „reicht nicht an GCC heran“ – die Maßstäbe verschieben sich ständig.
      Betrachtet man aber das Entwicklungstempo, scheint es plausibel, dass man mit ein paar Compiler-Ingenieuren schnell aufholen könnte.
    • Ein C-Compiler ist das Ergebnis von 50 Jahren angesammeltem Code.
      Deshalb bleibt fraglich, ob ein LLM wirklich völlig neue Probleme lösen kann.

  • Anthropic schrieb im Blog, dass der Linux-Kernel auch auf x86 bootet, tatsächlich scheint aber nur RISC-V erfolgreich gewesen zu sein
    Im offiziellen Post hieß es, x86/ARM/RISC-V würden alle funktionieren,
    in der Repo-Dokumentation gibt es jedoch nur Tests für RISC-V.

    • Möglicherweise könnte CCC funktionieren, wenn man static keys oder DKMS deaktiviert.

  • Spannend ist, wie stark die Leistungseinbußen bei nicht optimiertem C ausfallen
    Beim SQLite3-Build war CCC 12-mal langsamer, die optimierte Version sogar 20-mal.
    Das zeigt, wie viel Optimierungsleistung in GCC steckt.

    • Die Geschwindigkeit von C beruht weiterhin auf den Spracheigenschaften, die direkt mit der Hardware verbunden sind.
      Ein Compiler mit starkem Register-Shuffling verliert diesen Bezug jedoch und fühlt sich dann eher wie Python an.
    • Selbst schwach optimierende Compiler wie TCC sind deutlich schneller als CCC.
      Dass CCC sogar langsamer als -O0 ist, war überraschend.

  • Dass CCC alle C-Dateien des Kernels ohne Fehler kompiliert hat, heißt nicht, dass dabei korrekte Ergebnisse entstanden sind
    Allein das Bestehen von SQLite-Tests reicht nicht aus.

    • Keine Fehler zu melden bedeutet nicht automatisch korrekt zu kompilieren. Auch wenn man nach /dev/null schreibt, gibt es keine Fehler.
    • Laut einem Beitrag auf LinkedIn ignoriert CCC const und lässt auch Typ-Neudefinitionen oder fehlerhafte Casts einfach durch.
      Mit anderen Worten: Um das Ziel „Tests bestehen“ zu erreichen, wurde offenbar mit dem Trick gearbeitet, auch ungültigen Code zu kompilieren.

  • In manchen Beiträgen hieß es, „der Compiler sei der einfachste Teil“, tatsächlich ist aber der Linker der komplexeste Teil
    Tausende x86-64-Befehlsencodings und die detaillierten Layouts von ELF sind für AI schwer zu handhaben.

    • Als Gegenargument wurde angeführt, dass der Link-Schritt eher Regelanwendung sei und der Assembler eher Pattern Matching.
      Außerdem ergibt die Rechnung „eine Iteration 4-mal langsamer → eine Milliarde Iterationen 158.000-mal langsamer“ keinen Sinn.
    • Es gibt auch jemanden, der berichtet, Claude habe ihm in einem Zug einen x86-Assembler und Linker erzeugt.
      Viele Befehle hätten zwar gefehlt, aber es sei auf einem Niveau gewesen, bei dem nur noch Datentabellen aufgefüllt werden mussten.
    • Soweit bekannt, hat Anthropic nur den Compiler gebaut, nicht auch den Linker.

  • Erstaunlich ist, wie schnell sich menschliche Erwartungen verschieben
    Noch vor fünf Jahren wäre die Aussage „AI baut aus einem englischen Prompt einen C-Compiler“ ein absurder Witz gewesen.

    • Allerdings muss man auch bedenken, wie stark dieser Code von bestehenden Compiler-Quellen abhängig war.
    • Ohne Kontext könnte ein solches Ergebnis letztlich auch nur eine komplizierte Copy-pasta sein.
    • Diese Fortschritte sind beeindruckend, aber daraus unmittelbar die Ankunft von AGI abzuleiten, ist eine vorschnelle Verallgemeinerung.
    • Letztlich hat sich nur das Overton Window verschoben.
    • Man darf allerdings nicht ignorieren, dass dafür Trainingskosten in Milliardenhöhe und das Training auf dem gesamten Internet nötig waren.

  • Den übertriebenen Zynismus auf HN kann ich nicht nachvollziehen
    Einen C-Compiler für drei Architekturen zu bauen ist auch für Menschen schwierig,
    und selbst ein Niveau, das SQLite besteht, ist als Wochenendprojekt-Leistung bemerkenswert.
    Die meisten Unternehmen bauen in der Praxis keine Hochleistungscompiler, sondern Code-Klebstoff für Business-Logik.
    Das Problem liegt weniger in der Technik selbst als in der Haltung der Menschen, die sie benutzen.

    • Wenn man allerdings Token-Kosten von $20k und die Beteiligung mehrerer Personen berücksichtigt, ist „Wochenendprojekt“ übertrieben.
    • Dass CCC Fehler ignoriert und selbst die SQLite-Tests nicht vollständig sind, ist ein ernstes Problem.
    • Von LLMs erzeugter Code bleibt schwer zu korrigieren und hat weiterhin Grenzen, weil er eine fragile Struktur besitzt.
    • Am Ende ist nicht die Technik das Problem, sondern die Leute, die AI-Erfolge übermäßig aufblasen.
    • Der Ausdruck „sour grapes“ passt in diesem Kontext nicht besonders gut.

  • Die 158.000-fach langsamere Leistung bei SQLite ist der Kernpunkt
    Parsing ist das leichte Problem, wirklich schwierig sind Registerallokation und Optimierungsphase.
    Ein Vergleich mit GCC ist zwar wenig sinnvoll, aber dass ein LLM überhaupt so einen Compiler gebaut hat, ist bemerkenswert.
    Das nächste Ziel ist, die Lücke zu GCC von 158.000-fach auf etwa 100-fach zu verringern.

    • Allerdings ist diese Zahl schwer vertrauenswürdig.
      Wenn jede Iteration 12-mal langsamer ist, müsste insgesamt ebenfalls nur etwa der Faktor 12 herauskommen; 158.000-fach wirkt eher wie ein Fehler oder Missverständnis.
      Ob der SQLite-Test überhaupt korrekt ausgeführt wird, ist ebenfalls unzureichend verifiziert.
    • Das LLM hat wahrscheinlich den Quellcode von GCC oder Clang im Training gesehen.
      Trotzdem bleibt fraglich, warum die Leistung dann so schlecht ist.
    • Es wurde auch darauf hingewiesen, dass C-Parsing schwieriger ist, als man denkt.
      Empfehlenswert ist der Artikel C is not actually a fully parseable language.

  • Wie der Einwand „Wenn eine Iteration 8-mal langsamer ist, dann bleibt es auch bei einer Milliarde Iterationen nur 8-mal langsamer“ zeigt,
    ist die Zahl 158.000-fach logisch nicht stimmig.
    Möglicherweise hat Register-Spilling den L3-Cache überlastet oder ein Bug führt dazu, dass unnötiger Code ausgeführt wird.

    • Wenn die GCC-Version schon nach 0,047 Sekunden fertig ist, wirkt auch die Behauptung von „einer Milliarde Iterationen“ wenig glaubwürdig.

  • Einen C-Compiler zu bauen ist auch für Menschen schwierig,
    aber das als Beleg für die Intelligenz eines LLM zu sehen, überzeugt nicht wirklich
    Es handelt sich um ein bereits gut bekanntes Problem, und unzählige Implementierungen sowie Dokumentationen sind in den Trainingsdaten enthalten.
    Das LLM hat also kein neues Design geschaffen, sondern bestehende Muster neu zusammengesetzt.
    Trotzdem bleiben solche Werkzeuge nützlich,
    und wirklich beeindruckend wird es erst dann, wenn ein Modell nicht nur bestehende OSS repliziert, sondern neue Ansätze vorschlägt.