14 puntos por GN⁺ 2026-02-10 | 5 comentarios | Compartir por WhatsApp
  • CCC (Claude’s C Compiler), escrito completamente por Claude Opus 4.6 de Anthropic, fue publicado afirmando que puede compilar el kernel de Linux
  • Es un compilador independiente escrito en Rust que implementa por cuenta propia todos los componentes, desde el frontend hasta el linker, pero su rendimiento y calidad de optimización quedan muy por detrás de GCC
  • En benchmarks con SQLite y el kernel de Linux, CCC compiló todos los archivos C sin errores, pero la compilación falló en la etapa de enlazado por más de 40 mil errores de referencia
  • El rendimiento de ejecución de SQLite es hasta 158,000 veces más lento, el tamaño del binario es más de 3 veces mayor y las opciones de optimización (-O2, etc.) no tienen efecto
  • Que una IA haya generado un compilador de C completo es técnicamente significativo, pero todavía no alcanza un nivel de eficiencia y compatibilidad utilizable en la práctica

Resumen y estructura de CCC

  • CCC es un compilador de C escrito completamente por IA con Claude de Anthropic y soporta x86-64, i686, AArch64 y RISC-V 64
    • Está escrito en Rust e incluye IR basada en SSA, optimizador, generador de código, ensamblador, linker y generación de información de depuración DWARF
  • Explica por separado el papel del compilador, ensamblador y linker, y señala que el linker es el componente más complejo y con más probabilidad de errores
  • Como el kernel de Linux usa extensiones de GCC y scripts de enlazado complejos, no era adecuado como objetivo inicial de pruebas; en su lugar se eligió SQLite como benchmark principal

Entorno y método de prueba

  • Se compararon GCC 14.2.0 y CCC en dos VM basadas en Debian (6 vCPU, 16 GB de RAM) bajo las mismas condiciones
  • Criterios de comparación: tiempo de compilación, tamaño del binario, velocidad de ejecución, uso de memoria y estabilidad
  • CCC usa la función gcc_m16 para delegar a GCC únicamente el código de arranque de 16 bits, y procesar el resto con CCC
  • El benchmark de SQLite fue diseñado con foco en CPU y ejecuta 42 operaciones SQL en 10 etapas

Resumen de resultados principales

  • Kernel de Linux 6.9: CCC compiló los 2,844 archivos C, pero falló en la etapa de enlazado con 40,784 errores de undefined reference
    • Causas del error: relocations y generación de símbolos incorrectas en las secciones __jump_table y __ksymtab
  • Compilación de SQLite: CCC fue 1.3 veces más lento que GCC, con binarios 2.7 a 3 veces más grandes y uso de memoria 5.9 veces mayor
  • Rendimiento de ejecución de SQLite: 737 veces más lento que GCC -O0 y 1,242 veces más lento que GCC -O2
    • Las consultas simples fueron entre 1 y 7 veces más lentas, y las consultas con bucles anidados fueron hasta 158,000 veces más lentas
  • Superó los 5 tipos de pruebas de crash, por lo que se confirmó la corrección funcional

Causas de la caída de rendimiento

  • Exceso de register spilling: la mayoría de las variables locales se guardan en la pila, provocando un exceso de accesos a memoria
    • En la función sqlite3VdbeExec, más de 100 variables se manejan en la pila, y la longitud del código aumenta 3 veces
  • Opciones de optimización sin efecto: los resultados de -O0 y -O2 son completamente iguales, y las 15 pasadas SSA se ejecutan de la misma forma en todos los niveles
  • Corrupción del frame pointer, lo que impide depurar con GDB
  • Inflación del tamaño de código: el binario de SQLite pesa 4.27 MB, 2.78 veces más que con GCC, aumentando los fallos de caché de instrucciones
  • No se genera tabla de símbolos: no hay símbolos para funciones internas, por lo que no se puede perfilar

Fortalezas y limitaciones de CCC

  • Fortalezas
    • Compiló sin errores todos los archivos C del kernel de Linux
    • Los resultados de SQLite mostraron exactitud y estabilidad, sin segfaults
    • Soporta una interfaz de línea de comandos compatible con GCC
  • Limitaciones
    • Caída extrema del rendimiento de ejecución (hasta 158,000 veces)
    • Incompatibilidad del linker, lo que impide compilar el kernel
    • Tamaño del binario y uso de memoria excesivos
    • Falta de optimización e información de depuración; las opciones -O no tienen efecto
    • La velocidad de compilación también es 25% más lenta que la de GCC

El problema de “Hello World”

  • Poco después de su publicación apareció el issue “Hello world does not compile”
    • La fase de preprocesamiento fallaba por no encontrar stddef.h y stdarg.h
    • En GitHub generó conversación con más de 288 reacciones y alrededor de 200 comentarios
    • Algunos usuarios lo evaluaron como “más parecido a un proyecto de compiladores de nivel universitario”

Conclusión

  • CCC es un caso que demuestra que la IA puede generar un compilador de C completo
    • Procesó sin errores todos los archivos C del kernel de Linux y ejecutó SQLite con corrección funcional
  • Sin embargo, no es adecuado para uso real
    • El rendimiento de ejecución es extremadamente bajo y las funciones de linker, optimización y depuración están incompletas
  • Como logro de investigación tiene valor, pero como compilador para trabajo práctico, herramientas existentes como GCC y Clang siguen siendo indispensables

5 comentarios

 
roxie 2026-02-10

Así que de aquí salió el meme de "Hello world does not compile" jajaja

 
fantajeon 2026-02-13

Al principio se siente parecido al ambiente del baduk.

 
chcv0313 2026-02-12

Si sigues iterando en un bucle y pidiéndole que lo corrija, ¿no terminará saliendo algún día un compilador aún mejor?

 
t7vonn 2026-02-11

Parece que hay que darle mérito por haber llegado al nivel de una tarea de pregrado..

 
GN⁺ 2026-02-10
Comentarios en Hacker News
  • Esta discusión muestra bien las dos posturas sobre los agentes de programación con LLM
    Los que están a favor dicen: “es impresionante que haya hecho un compilador funcional en unas horas”, y los que están en contra dicen: “si no funciona, no sirve de nada”
    Cuanto más complejo es el codebase, más débiles se vuelven los agentes, y hay escepticismo ante la afirmación repetida de que “la siguiente generación lo arreglará”
    Anthropic dijo que compiló el kernel de Linux, pero en realidad falló, y eso deja ver la brecha entre las expectativas infladas sobre la IA y la realidad

    • Hace recordar el reciente caso de OCaml ‘vibe coded’
      Pasar pruebas y producir una salida aparentemente correcta es algo completamente distinto a que ese código tenga calidad mantenible
    • Cada vez que se repite la lógica de “la siguiente generación de modelos lo va a arreglar todo”, da fastidio
    • Tal vez haga falta una página del wiki C2 para “sufficiently smart LLM”
    • Esta discusión se parece a ver el proceso de avance de SpaceX
      Al principio era “solo puede escribir funciones pequeñas”, luego “no puede compilar Linux”, después “no llega al nivel de GCC”, y así el criterio sigue cambiando
      Pero viendo la velocidad de avance, parece que con solo sumar unos cuantos ingenieros de compiladores podrían alcanzarlo rápido
    • Un compilador de C es el resultado de 50 años de código acumulado
      Por eso sigue habiendo dudas sobre si un LLM puede resolver problemas realmente nuevos por completo
  • Anthropic dijo en su blog que el kernel de Linux también arrancaba en x86, pero en realidad parece que solo tuvo éxito en RISC-V
    En el post oficial dijeron que funcionaba en x86/ARM/RISC-V,
    pero en la documentación del repositorio solo aparecen pruebas en RISC-V

    • Quizá CCC podría funcionar si se desactivan static keys, DKMS y similares
  • Es interesante ver cuánto cae el rendimiento de C sin optimización
    En la compilación de SQLite3, CCC es 12 veces más lento, y la versión optimizada 20 veces más lenta
    Eso muestra cuántos logros de optimización ha conseguido GCC

    • La velocidad de C sigue viniendo de las características del lenguaje, directamente ligadas al hardware
      Pero si el compilador hace demasiado barajado de registros, se pierde esa relación y termina sintiéndose como Python
    • Incluso un compilador de baja optimización como TCC es mucho más rápido que CCC
      Sorprendió que CCC fuera más lento incluso que -O0
  • Que CCC haya compilado todos los archivos C del kernel sin errores no significa que haya producido un resultado correcto
    Pasar las pruebas de SQLite por sí solo no alcanza

    • No tener errores no significa compilar correctamente. Mandarlo a /dev/null tampoco da errores
    • Según una publicación vista en LinkedIn, CCC ignora const y también deja pasar redefiniciones de tipos o conversiones incorrectas
      O sea, parece haber usado el truco de compilar incluso código inválido para cumplir la meta de “pasar las pruebas”
  • En algunos textos se decía que “el compilador es la parte más fácil”, pero en realidad el linker es la parte más compleja
    Los miles de codificaciones de instrucciones de x86-64 y el layout detallado de ELF son cosas difíciles de manejar para la IA

    • También hay quien responde que el proceso de enlace se parece más a aplicar reglas, y el ensamblador a hacer pattern matching
      Además, el cálculo de “4 veces más lento en una iteración → 158,000 veces más lento en mil millones de iteraciones” no tiene sentido
    • Hay quien dice que Claude le creó de una sola vez un ensamblador y linker para x86
      Faltaban muchas instrucciones, pero estaba al nivel de solo tener que llenar tablas de datos
    • Según entiendo, lo que hizo Anthropic fue un compilador, no un linker
  • Sorprende lo rápido que cambian las expectativas humanas
    Hace apenas 5 años, decir que “la IA crea un compilador de C a partir de un prompt en inglés” habría sonado como una broma absurda

    • Pero también hay que pensar cuánto dependía ese código del código fuente de compiladores ya existentes
    • Si este resultado apareciera sin contexto, en realidad podría ser una especie de copy-paste complejo (copy-pasta)
    • Que este avance sea sorprendente no significa que sirva para predecir la llegada de la AGI; eso sería una generalización apresurada
    • Al final, creo que lo único que pasó es que se movió la ventana de Overton
    • Aun así, no se puede ignorar el hecho de que se entrenó con miles de millones de dólares y con todo internet
  • No se entiende el exceso de cinismo en HN
    Hacer un compilador de C para tres arquitecturas también es difícil para un humano,
    y aunque solo llegue al nivel de pasar SQLite, sigue siendo un resultado impresionante para un proyecto de fin de semana
    La mayoría de las empresas en la práctica no hacen compiladores de alto rendimiento, sino pegamento de código para lógica de negocio
    El problema no está tanto en la tecnología en sí, sino en la actitud de quienes la usan

    • Pero considerando el costo de tokens de $20k y la intervención de varias personas, llamarlo “proyecto de fin de semana” es exagerado
    • Que CCC ignore errores y que ni siquiera las pruebas de SQLite estén completas es algo serio
    • El código hecho por LLM sigue teniendo límites porque es difícil de modificar y tiene una estructura frágil
    • Al final, el problema no es la tecnología, sino la gente que sobrevende los logros de la IA
    • La expresión “sour grapes” no encaja bien en este contexto
  • Lo clave en SQLite es el rendimiento 158,000 veces más lento
    El parsing es la parte fácil, y lo realmente difícil es la asignación de registros y la fase de optimización
    Compararlo con GCC no tiene mucho sentido, pero el simple hecho de que un LLM haya hecho este compilador ya es sorprendente
    El siguiente objetivo es reducir la brecha con GCC de 158,000 veces a algo como 100 veces

    • Pero es difícil confiar en ese cálculo
      Si cada iteración es 12 veces más lenta, el total también debería ser 12 veces más lento, así que 158,000 veces parece un error o malentendido
      También falta verificar si la prueba de SQLite realmente se ejecuta correctamente
    • Es muy probable que el LLM haya aprendido el código fuente de GCC o Clang
      Aun así, queda la duda de por qué el rendimiento sale tan bajo
    • También hay quien señala que hacer parsing de C es más difícil de lo que parece
      Vale la pena revisar el texto C no es un lenguaje completamente parseable
  • Como señalan algunos, “si una iteración es 8 veces más lenta, incluso repitiéndola mil millones de veces sigue siendo solo 8 veces más lenta”,
    así que la cifra de 158,000 veces no cuadra lógicamente
    Quizá el register spilling terminó saturando la caché L3, o hay un bug que hace que se ejecute código innecesario

    • Viendo que la versión con GCC terminó en apenas 0.047 segundos, también cuesta creer la afirmación de “mil millones de iteraciones”
  • Hacer un compilador de C también es difícil para los humanos,
    pero cuesta verlo como una prueba de inteligencia del LLM
    Es un problema ya muy conocido, y hay muchísimas implementaciones y documentación incluidas en los datos de entrenamiento
    Es decir, el LLM no creó un diseño nuevo, sino que recombinó patrones existentes
    Aun así, este tipo de herramientas sigue siendo útil,
    y lo realmente impresionante será cuando aparezca un modelo que no solo replique OSS existente, sino que proponga enfoques nuevos