Comparaison entre le compilateur C généré par Claude et GCC

• CCC (Claude’s C Compiler), entièrement écrit par Claude Opus 4.6 d’Anthropic, a été publié en affirmant pouvoir compiler le noyau Linux
• Ce compilateur autonome écrit en Rust implémente lui-même tous les composants, du frontend au linker, mais ses performances et la qualité de ses optimisations restent très inférieures à celles de GCC
• Lors de benchmarks sur SQLite et le noyau Linux, CCC a compilé tous les fichiers C sans erreur, mais la compilation a échoué à l’étape du linker avec plus de 40 000 erreurs de référence
• Les performances d’exécution de SQLite sont jusqu’à 158 000 fois plus lentes, la taille du binaire est plus de 3 fois supérieure, et les options d’optimisation (-O2, etc.) sont sans effet
• Le fait qu’une IA ait généré un compilateur C complet est significatif sur le plan technique, mais le niveau d’efficacité et de compatibilité reste insuffisant pour un usage réel

---

Vue d’ensemble et architecture de CCC

• CCC est un compilateur C entièrement écrit par une IA à l’aide de Claude par Anthropic, avec prise en charge de x86-64, i686, AArch64 et RISC-V 64
  • Écrit en Rust, il inclut un IR basé sur SSA, un optimiseur, un générateur de code, un assembleur, un linker et même la génération d’informations de débogage DWARF
• L’article distingue les rôles du compilateur, de l’assembleur et du linker, en précisant que le linker est le plus complexe et le plus susceptible de provoquer des erreurs
• Comme le noyau Linux utilise des extensions GCC et des scripts de linkage complexes, il n’était pas adapté comme première cible de test ; SQLite a donc été choisi comme benchmark principal

Environnement et méthode de test

• Comparaison entre GCC 14.2.0 et CCC dans les mêmes conditions sur deux VM basées sur Debian (6 vCPU, 16 Go de RAM)
• Éléments comparés : temps de compilation, taille du binaire, vitesse d’exécution, consommation mémoire, stabilité
• CCC délègue uniquement le code de démarrage 16 bits à GCC via la fonctionnalité gcc_m16, et traite tout le reste lui-même
• Le benchmark SQLite, centré sur le CPU, exécute 42 opérations SQL en 10 étapes

Résumé des principaux résultats

• Noyau Linux 6.9 : CCC a compilé les 2 844 fichiers C, mais a échoué à l’étape du linker avec 40 784 erreurs d’undefined reference
  • Cause des erreurs : mauvaises relocations et génération de symboles dans les sections __jump_table et __ksymtab
• Compilation de SQLite : CCC est 1,3 fois plus lent que GCC, avec un binaire 2,7 à 3 fois plus gros et une consommation mémoire 5,9 fois supérieure
• Performances d’exécution de SQLite : 737 fois plus lent que GCC -O0, et 1 242 fois plus lent que GCC -O2
  • Les requêtes simples sont 1 à 7 fois plus lentes, tandis que les requêtes à boucles imbriquées peuvent être jusqu’à 158 000 fois plus lentes
• Les 5 tests de crash ont tous été réussis, ce qui confirme la correction fonctionnelle

Causes de la dégradation des performances

• Spilling excessif des registres : la plupart des variables locales sont stockées sur la pile, provoquant un excès d’accès mémoire
  • Dans la fonction sqlite3VdbeExec, plus de 100 variables sont gérées via la pile, ce qui triple la longueur du code
• Options d’optimisation sans effet : les résultats de -O0 et -O2 sont strictement identiques, les 15 passes SSA étant exécutées de la même manière à tous les niveaux
• Corruption du frame pointer, rendant le débogage avec GDB impossible
• Gonflement de la taille du code : le binaire SQLite atteint 4,27 Mo, soit 2,78 fois la taille obtenue avec GCC, ce qui augmente les défauts de cache d’instructions
• Absence de table des symboles : impossible de profiler faute de symboles pour les fonctions internes

Forces et limites de CCC

• Forces
  • Compile sans erreur tous les fichiers C du noyau Linux
  • Garantit la justesse et la stabilité des résultats sur SQLite, sans segfault
  • Prend en charge une interface en ligne de commande compatible avec GCC
• Limites
  • Vitesse d’exécution extrêmement dégradée (jusqu’à 158 000 fois plus lente)
  • Échec de la compilation du noyau en raison d’une incompatibilité du linker
  • Taille du binaire et consommation mémoire excessives
  • Absence d’optimisation et d’informations de débogage, options -O sans effet
  • Vitesse de compilation également inférieure à GCC, d’environ 25 %

Le problème du « Hello World »

• Peu après la publication, un problème intitulé « Hello world does not compile » est apparu
  • Échec à l’étape de prétraitement faute de trouver stddef.h et stdarg.h
  • Le sujet a attiré l’attention sur GitHub avec plus de 288 réactions et environ 200 commentaires
  • Certains utilisateurs l’ont jugé « semblable à un projet de compilateur de niveau licence »

Conclusion

• CCC constitue un cas concret montrant qu’une IA peut générer un compilateur C complet
  • Il traite sans erreur tous les fichiers C du noyau Linux et exécute SQLite avec une correction fonctionnelle
• Cependant, il reste inadapté à un usage réel
  • Les performances d’exécution sont extrêmement faibles, et les fonctions de linkage, d’optimisation et de débogage restent inachevées
• En tant que réussite de recherche, le projet a de l’intérêt, mais pour un compilateur de production, les outils existants comme GCC et Clang restent indispensables

[roxie]

Donc c’est de là que vient le mème « Hello world does not compile » lol

[fantajeon]

Au début, l’ambiance ressemble un peu à celle du baduk.

[chcv0313]

Si on lui demande de corriger en boucle, est-ce qu’on ne finira pas par obtenir un compilateur encore meilleur ?

[t7vonn]

On peut sans doute considérer comme significatif le fait qu’on soit arrivé au niveau d’un devoir d’étudiant de licence.

[GN⁺]

Réactions sur Hacker News

• Cette polémique illustre bien les deux points de vue opposés sur les agents de codage LLM
  Les partisans disent : « c’est impressionnant d’avoir produit un compilateur fonctionnel en quelques heures », tandis que les critiques répondent : « s’il ne fonctionne pas correctement, ça ne vaut rien ».
  Plus la base de code est complexe, plus l’agent semble perdre en efficacité, et beaucoup restent sceptiques face au refrain récurrent du « la prochaine génération corrigera ça ».
  Anthropic a affirmé avoir compilé le noyau Linux, mais cela a en réalité échoué, ce qui met en évidence l’écart entre les attentes gonflées autour de l’IA et la réalité.

  • Cela rappelle le récent incident OCaml « vibe coded »
    Réussir des tests et produire une sortie apparemment correcte n’a rien à voir avec le fait d’avoir un code de qualité maintenable
  • Cette logique du « la prochaine génération de modèles corrigera tout » devient agaçante à force d’être répétée
  • Il nous faudrait peut-être une page du wiki C2 sur le « sufficiently smart LLM »
  • Ce débat fait un peu penser à l’évolution de SpaceX
    Au début, on disait « il ne peut écrire que de petites fonctions », puis « il ne peut pas compiler Linux », puis « il n’atteint pas le niveau de GCC », en déplaçant sans cesse les critères.
    Mais vu la vitesse des progrès, on a l’impression qu’avec seulement quelques ingénieurs compilateur, le retard pourrait être rattrapé rapidement
  • Un compilateur C est le résultat de 50 ans d’accumulation de code
    Il reste donc légitime de douter qu’un LLM puisse résoudre de vrais problèmes entièrement nouveaux

• Anthropic a écrit sur son blog que le noyau Linux démarrait aussi sur x86, mais il semble qu’en pratique seul RISC-V ait réussi
  Le post officiel affirme que cela fonctionne sur x86/ARM/RISC-V,
  mais la documentation du dépôt ne montre que des tests sur RISC-V

  • Il est possible que CCC fonctionne aussi si l’on désactive static keys ou DKMS, par exemple

• Il est intéressant de voir l’ampleur de la dégradation des performances d’un C non optimisé
  Sur le build SQLite3, CCC est 12 fois plus lent, et la version optimisée 20 fois plus lente
  Cela montre à quel point GCC obtient de vrais gains d’optimisation

  • La vitesse du C reste encore liée au fait que le langage est directement connecté au matériel
    Mais avec un compilateur qui fait trop de brassage de registres, ce lien se perd et les performances donnent l’impression d’être au niveau de Python
  • Même un compilateur peu optimisé comme TCC est bien plus rapide que CCC
    Il était surprenant que CCC soit encore plus lent que -O0

• Le fait que CCC compile tous les fichiers C du noyau sans erreur ne signifie pas qu’il produit un résultat correct
  Réussir les tests SQLite ne suffit pas

  • L’absence d’erreurs ne veut pas dire que la compilation est correcte. On peut aussi tout envoyer vers /dev/null sans erreur
  • D’après un message vu sur LinkedIn, CCC ignore const et laisse passer des redéfinitions de types ou des conversions invalides
    Autrement dit, il aurait triché en compilant même du code invalide pour atteindre l’objectif de « faire passer les tests »

• Certains disent que « le compilateur est la partie la plus facile », mais en réalité le linker est la partie la plus complexe
  Les milliers d’encodages d’instructions en x86-64, ou encore la disposition détaillée d’ELF, sont difficiles à traiter pour une IA

  • En réponse, d’autres font valoir que l’étape de linkage relève surtout de l’application de règles, et que l’assembleur ressemble plutôt à du pattern matching
    De même, le calcul du type « 4 fois plus lent sur une itération → 158 000 fois plus lent sur un milliard d’itérations » n’a aucun sens
  • Quelqu’un affirme aussi que Claude lui a généré en une fois un assembleur et un linker x86
    Il manquait beaucoup d’instructions, mais cela restait apparemment au niveau de simples tables de données à compléter
  • À ma connaissance, ce qu’Anthropic a construit était un compilateur, pas un linker

• Il est frappant de voir à quelle vitesse les attentes humaines changent
  Il y a cinq ans à peine, dire qu’une IA fabriquerait un compilateur C à partir d’un prompt en anglais aurait semblé être une blague absurde

  • Mais il faut aussi se demander dans quelle mesure ce code dépend du source des compilateurs existants
  • Sans contexte, un tel résultat peut aussi ressembler à une forme de copier-coller complexe (copy-pasta)
  • Ces progrès sont impressionnants, mais s’en servir pour prédire l’arrivée de l’AGI relève d’une généralisation hâtive
  • Au fond, on peut aussi y voir un simple déplacement de la fenêtre d’Overton
  • Cela dit, on ne peut pas ignorer les milliards de dollars investis dans l’entraînement, ni le fait que le modèle a appris sur l’ensemble d’Internet

• Le cynisme excessif de HN est difficile à comprendre
  Construire un compilateur C pour trois architectures est déjà difficile pour un humain,
  et même le niveau atteint sur SQLite constitue une performance remarquable pour un projet de week-end
  Dans la plupart des entreprises, la réalité n’est pas de produire des compilateurs ultra-performants, mais de créer du code glue pour la logique métier
  Le vrai problème ne tient pas tant à la technologie qu’à l’attitude de ceux qui l’utilisent

  • Mais en tenant compte du coût de tokens à $20k et de l’intervention de plusieurs personnes, parler de « projet de week-end » est exagéré
  • Le fait que CCC ignore les erreurs et que même les tests SQLite ne soient pas complets est un problème sérieux
  • Le code généré par LLM reste difficile à corriger et garde des structures fragiles, ce qui montre encore ses limites
  • Au final, le problème n’est pas la technologie, mais ceux qui survendent les résultats de l’IA
  • L’expression « sour grapes » ne paraît pas adaptée dans ce contexte

• Le point clé, c’est la performance 158 000 fois plus lente sur SQLite
  Le parsing est relativement facile ; les vraies difficultés sont l’allocation de registres et l’optimisation
  Comparer cela à GCC n’a pas vraiment de sens, mais le simple fait qu’un LLM ait produit un tel compilateur reste impressionnant
  Le prochain objectif serait de réduire l’écart avec GCC de 158 000 fois à quelque chose comme 100 fois

  • Mais ce calcul paraît difficile à croire
    Si chaque itération est 12 fois plus lente, l’ensemble devrait aussi être 12 fois plus lent ; 158 000 fois ressemble plutôt à une erreur ou un malentendu
    Il manque aussi des vérifications pour savoir si le test SQLite s’exécute réellement correctement
  • Le LLM a probablement appris à partir du code source de GCC ou de Clang
    Malgré cela, il est surprenant que les performances soient aussi faibles
  • Certains rappellent aussi que le parsing du C est plus difficile qu’il n’y paraît
    Voir par exemple C n’est pas un langage entièrement parsable

• Comme le souligne la remarque « si une itération est 8 fois plus lente, alors un milliard d’itérations restent simplement 8 fois plus lentes »,
  le chiffre de 158 000 fois est logiquement incohérent
  Il se peut que du register spilling ait saturé le cache L3, ou qu’un bug fasse exécuter du code inutile

  • Le fait que la version GCC termine en 0,047 seconde rend aussi peu crédible l’affirmation sur « un milliard d’itérations »

• Construire un compilateur C est difficile même pour un humain,
  mais il est difficile d’y voir une preuve d’intelligence du LLM
  Le problème est déjà bien connu, et il existe d’innombrables implémentations et documents dans les données d’entraînement
  Autrement dit, le LLM n’a pas créé une nouvelle conception ; il a surtout recombiné des patterns existants
  Cela n’empêche pas ces outils d’être utiles,
  et ce qui sera vraiment impressionnant, ce sera l’arrivée de modèles capables non pas de répliquer de l’OSS existant, mais de proposer une approche réellement nouvelle