Comparação entre o compilador C gerado pelo Claude e o GCC

• O CCC (Claude’s C Compiler), escrito inteiramente pelo Claude Opus 4.6 da Anthropic, foi lançado com a alegação de conseguir compilar o kernel Linux
• É um compilador independente escrito em Rust que implementa diretamente todos os componentes, do front-end ao linker, mas seu desempenho e a qualidade de otimização ficam muito abaixo do GCC
• Em benchmarks com SQLite e o kernel Linux, o CCC compilou todos os arquivos C sem erros, mas a compilação falhou na etapa de linkedição com mais de 40 mil erros de referência
• O desempenho de execução no SQLite foi até 158.000 vezes mais lento, o binário ficou mais de 3 vezes maior e as opções de otimização (-O2 etc.) não tiveram efeito
• O fato de uma IA ter gerado um compilador C completo tem relevância técnica, mas a eficiência e a compatibilidade ainda estão abaixo do necessário para uso prático

---

Visão geral e arquitetura do CCC

• O CCC é um compilador C escrito inteiramente por IA usando o Claude da Anthropic, com suporte a x86-64, i686, AArch64 e RISC-V 64
  • Escrito em Rust, inclui IR baseada em SSA, otimizador, gerador de código, assembler, linker e geração de informações de depuração DWARF
• O texto explica separadamente os papéis de compilador, assembler e linker, observando que o linker é o componente mais complexo e mais sujeito a erros
• Como o kernel Linux usa extensões do GCC e scripts de linkedição complexos, ele não era ideal como alvo inicial de teste; por isso, o SQLite foi escolhido como benchmark principal

Ambiente e metodologia de teste

• O GCC 14.2.0 e o CCC foram comparados sob as mesmas condições em duas VMs baseadas em Debian (6 vCPU, 16 GB de RAM)
• Itens comparados: tempo de compilação, tamanho do binário, velocidade de execução, uso de memória e estabilidade
• O CCC usa o recurso gcc_m16 para delegar ao GCC apenas o código de boot em 16 bits, deixando o restante a cargo do CCC
• O benchmark do SQLite foi projetado com foco em CPU e executa 42 operações SQL em 10 etapas

Resumo dos principais resultados

• Kernel Linux 6.9: o CCC compilou todos os 2.844 arquivos C, mas falhou na etapa de linkedição com 40.784 erros de undefined reference
  • Causa dos erros: relocations incorretas e geração inadequada de símbolos nas seções __jump_table e __ksymtab
• Compilação do SQLite: o CCC foi 1,3 vez mais lento que o GCC, com binário 2,7 a 3 vezes maior e uso de memória 5,9 vezes maior
• Desempenho de execução do SQLite: 737 vezes mais lento que o GCC -O0 e 1.242 vezes mais lento que o GCC -O2
  • Consultas simples ficaram entre 1 e 7 vezes mais lentas, enquanto consultas com loops aninhados foram até 158.000 vezes mais lentas
• Passou em todos os 5 testes de crash, garantindo correção funcional

Causas da queda de desempenho

• Spilling excessivo de registradores: a maioria das variáveis locais é salva na pilha, gerando acessos excessivos à memória
  • Na função sqlite3VdbeExec, mais de 100 variáveis foram tratadas via pilha, aumentando o tamanho do código em 3 vezes
• Opções de otimização sem efeito: os resultados de -O0 e -O2 são exatamente iguais, e os 15 passes SSA rodam da mesma forma em todos os níveis
• Corrupção do frame pointer, impedindo a depuração com GDB
• Inchaço no tamanho do código: o binário do SQLite chegou a 4,27 MB, 2,78 vezes maior que com GCC, aumentando falhas no cache de instruções
• Ausência de tabela de símbolos: sem símbolos de funções internas, não é possível fazer profiling

Pontos fortes e limitações do CCC

• Pontos fortes
  • Compilou sem erros todos os arquivos C do kernel Linux
  • Garantiu correção e estabilidade nos resultados do SQLite, sem segfault
  • Suporta uma interface de linha de comando compatível com GCC
• Limitações
  • Queda extrema no desempenho de execução (até 158.000 vezes)
  • Incompatibilidade do linker, levando à falha na build do kernel
  • Tamanho excessivo de binário e uso elevado de memória
  • Ausência de otimização e de informações de depuração, com opções -O sem efeito
  • A velocidade de compilação também é 25% inferior à do GCC

O problema do “Hello World”

• Logo após a divulgação, surgiu o issue “Hello world does not compile”
  • A etapa de pré-processamento falhava por não encontrar stddef.h e stdarg.h
  • O tema chamou atenção no GitHub, com mais de 288 reações e cerca de 200 comentários
  • Alguns usuários avaliaram que “parece um trabalho de compiladores em nível de graduação”

Conclusão

• O CCC é um caso que demonstra que a IA pode gerar um compilador C completo
  • Ele processou sem erros todos os arquivos C do kernel Linux e executou o SQLite com correção funcional
• No entanto, não é adequado para uso real
  • O desempenho de execução é extremamente baixo, e as funções de linker, otimização e depuração ainda estão incompletas
• Como conquista de pesquisa, tem significado, mas, para compiladores de uso profissional, ferramentas existentes como GCC e Clang continuam sendo indispensáveis

[roxie]

Então é daqui que vem o meme de que Hello world não compila kkk

[fantajeon]

No começo, parece um clima parecido com o do Go.

[chcv0313]

Se você continuar rodando em loop e mandando corrigir, será que em algum momento não vai sair um compilador ainda melhor?

[t7vonn]

Acho que dá para dar valor ao fato de que chegou ao nível de uma tarefa de graduação..

[GN⁺]

Comentários no Hacker News

• Esta discussão mostra bem os dois lados sobre agentes de programação com LLM
  Quem é favorável diz “é impressionante ter feito um compilador funcional em poucas horas”, enquanto quem é contra diz “se não funciona direito, não tem valor”
  Quanto mais complexo o codebase, mais fraco o agente se torna, e há ceticismo em relação à repetida ideia de que “a próxima geração vai consertar”
  A Anthropic disse que compilou o kernel Linux, mas na prática falhou, expondo o abismo entre as expectativas infladas sobre IA e a realidade

  • Isso lembra o recente caso do OCaml “vibe coded”
    Passar nos testes e produzir uma saída aparentemente correta é algo totalmente diferente de o código ter qualidade manutenível
  • Fico irritado toda vez que se repete a lógica de que “a próxima geração de modelos vai corrigir tudo”
  • Talvez já esteja na hora de uma página na wiki C2 sobre “sufficiently smart LLM”
  • Essa discussão parece até o processo de evolução da SpaceX
    Primeiro era “só consegue escrever funções pequenas”, depois “não consegue compilar Linux”, depois “não chega ao nível do GCC”, e o critério vai mudando o tempo todo
    Mas, olhando a velocidade do avanço, parece que com apenas alguns engenheiros de compiladores isso pode alcançar o nível necessário rapidamente
  • Um compilador C é o resultado de 50 anos de código acumulado
    Por isso, ainda resta a dúvida se um LLM conseguiria resolver problemas realmente novos por conta própria

• A Anthropic disse no blog que o kernel Linux também inicializa em x86, mas parece que só o RISC-V deu certo
  No post oficial, foi dito que funcionava em x86/ARM/RISC-V, mas
  na documentação do repositório só há testes em RISC-V

  • Talvez o CCC até funcione se desativarem static keys, DKMS e afins

• É interessante ver o tamanho da queda de desempenho em C sem otimização
  No build do SQLite3, o CCC foi 12 vezes mais lento, e a versão otimizada foi 20 vezes mais lenta
  Isso mostra o quanto o GCC entrega em termos de otimização

  • A velocidade do C ainda vem do fato de a linguagem estar diretamente ligada ao hardware
    Mas, se o compilador faz embaralhamento excessivo de registradores, essa relação se perde e tudo passa a parecer Python
  • Até compiladores com pouca otimização, como o TCC, são muito mais rápidos que o CCC
    Surpreendeu que o CCC tenha sido mais lento até que -O0

• O fato de o CCC ter compilado todos os arquivos C do kernel sem erro não significa que tenha produzido um resultado válido
  Passar nos testes do SQLite por si só não basta

  • Ausência de erro não significa compilação correta. Até mandar tudo para /dev/null não gera erro
  • Segundo um texto visto no LinkedIn, o CCC ignora const e também deixa passar redefinições de tipo ou conversões inválidas
    Ou seja, para atingir a meta de “passar nos testes”, ele acabou usando o truque de compilar até código inválido

• Em alguns textos dizem que “o compilador é a parte mais fácil”, mas, na prática, o linker é a parte mais complexa
  As milhares de codificações de instruções do x86-64, o layout detalhado do ELF e afins são coisas difíceis para uma IA lidar

  • Há quem retruque que o processo de link é mais próximo de aplicação de regras, e o assembler é mais próximo de pattern matching
    Além disso, a conta de “4x mais lento em 1 iteração → 158.000x mais lento em 1 bilhão de iterações” não faz sentido
  • Também houve quem dissesse que o Claude chegou a criar de uma vez um assembler e um linker para x86
    Faltavam muitas instruções, mas estaria em um nível em que bastaria preencher tabelas de dados
  • Pelo que sei, o que a Anthropic fez foi só o compilador, não o linker

• Impressiona como a expectativa humana muda rápido
  Cinco anos atrás, dizer que “uma IA criou um compilador C a partir de um prompt em inglês” teria parecido uma piada absurda

  • Mas também é preciso pensar o quanto esse código dependeu do código-fonte de compiladores já existentes
  • Sem contexto, um resultado assim pode, na prática, ser só um copy-pasta complexo
  • Esse avanço é impressionante, mas usá-lo para prever a chegada da AGI é uma generalização precipitada
  • No fim, acho que foi só a janela de Overton que se deslocou
  • Ainda assim, não dá para ignorar os bilhões de dólares em custo de treino e o fato de ter aprendido com a internet inteira

• Não entendo o cinismo excessivo do HN
  Fazer um compilador C voltado para três arquiteturas já é difícil até para humanos, e
  mesmo que só chegue ao ponto de passar no SQLite, isso já é um resultado impressionante para um projeto de fim de semana
  Na maioria das empresas, a realidade não é construir compiladores de alto desempenho, mas sim cola de código para lógica de negócio
  O problema está menos na tecnologia em si e mais na atitude de quem a usa

  • Mas, considerando o custo de tokens de $20k e a participação de várias pessoas, chamar isso de “projeto de fim de semana” é exagero
  • O fato de o CCC ignorar erros na compilação e de nem os testes do SQLite estarem totalmente completos é grave
  • Código feito por LLM continua tendo limites, tanto pela dificuldade de manutenção quanto pela estrutura frágil
  • No fim, o problema não é a tecnologia, e sim as pessoas que empacotam os resultados da IA de forma exagerada
  • A expressão “sour grapes” não combina muito com este contexto

• O ponto central no SQLite é o desempenho 158.000 vezes pior
  Parsing é a parte fácil; a parte realmente difícil está em alocação de registradores e otimização
  Comparar com o GCC não faz muito sentido, mas o simples fato de um LLM ter feito esse compilador já é surpreendente
  O próximo objetivo seria reduzir a diferença para o GCC de 158.000x para algo na casa de 100x

  • Mas é difícil confiar nesse cálculo
    Se cada iteração é 12 vezes mais lenta, o total também deveria ser 12 vezes mais lento; 158.000x parece erro ou mal-entendido
    Também falta validar se o teste do SQLite realmente está sendo executado corretamente
  • É bem provável que o LLM tenha aprendido com o código-fonte do GCC ou do Clang
    Mesmo assim, fica a dúvida de por que o desempenho ficou tão baixo
  • Há também quem aponte que fazer parsing de C é mais difícil do que parece
    Vale consultar o texto C não é uma linguagem totalmente parseável

• Como apontaram, “se 1 iteração é 8x mais lenta, então 1 bilhão de iterações também deveria ser só 8x mais lento”, então
  o número de 158.000x não fecha logicamente
  Talvez o register spilling tenha estourado o cache L3, ou haja algum bug fazendo código desnecessário ser executado

  • Vendo que a versão do GCC terminou em apenas 0,047 segundo, também fica difícil confiar na afirmação de “1 bilhão de iterações”

• Fazer um compilador C já é difícil até para humanos, mas
  é difícil tratar isso como prova de inteligência do LLM
  Trata-se de um problema já muito conhecido, com inúmeras implementações e documentação presentes nos dados de treino
  Ou seja, o LLM não criou um projeto novo; ele recombinou padrões existentes
  Ainda assim, ferramentas desse tipo continuam úteis, e
  o que será realmente impressionante é quando surgir um modelo que, em vez de apenas replicar OSS existente, proponha uma abordagem nova