Tradução de C para Rust fica até 62,2% mais lenta, diz paper

O que aconteceu

O estudo, registrado como arXiv:2610.23044v1 na categoria cs.AI, acompanhou 20 projetos reais escritos em C e as versões geradas pelo transpiler crust. Nos oito projetos escolhidos para a análise detalhada, o Rust traduzido ficou mais de 3% mais lento que o C original em 12 das 19 operações medidas. A diferença máxima chegou a 62,2%.

O diagnóstico saiu da comparação de três artefatos para cada par C-Rust: perfis de custo de execução, o LLVM IR já otimizado e os optimization remarks emitidos pelo compilador. O cruzamento apontou nove problemas recorrentes, distribuídos em três famílias. A primeira é trabalho residual de runtime que sobra na versão em Rust. A segunda são otimizações que o compilador deixa de aplicar. A terceira são padrões de código herdados do C que atrapalham o Rust. Para cada um dos nove, os autores derivaram uma direção de otimização.

Com essa lista em mãos, o time construiu uma ferramenta baseada em LLM que trata os nove problemas como regras reutilizáveis. O sistema perfila o projeto para localizar as funções quentes, casa cada uma com padrões específicos de regra e pede ao modelo que confira as precondições de reescrita contra o contexto do código antes de alterar qualquer linha. Uma reescrita só é mantida se passar em duas validações, a funcional e a de performance.

O teste final usou 41 operações de doze projetos mantidos fora da análise inicial. A ferramenta preservou a saída do C em todas as cargas testadas e acelerou 40 operações em relação às traduções do crust. Em 18 delas, o Rust otimizado terminou mais rápido que o próprio C original.

Contexto

Rust vem sendo adotado como sucessor seguro em memória do C, e transpiladores como o crust conseguem migrar projetos inteiros preservando o comportamento do programa. O paper ataca exatamente a brecha dessa promessa: preservar comportamento não garante preservar performance. Um código pode devolver exatamente as mesmas saídas e, ainda assim, gastar mais tempo em cada chamada.

O método dos autores foi menos sobre medir e mais sobre explicar. Ao colocar lado a lado o perfil de execução, o LLVM IR otimizado e os avisos do compilador de cada par C-Rust, o estudo conseguiu isolar de onde vinha o tempo perdido, em vez de apenas registrar que o Rust era mais lento. É esse mapa que sustenta as nove regras usadas depois pela ferramenta de LLM.

Por que importa

A conta da migração muda de lugar. Empresas que trocam C por Rust para eliminar classes inteiras de falhas de memória passam a ter um custo escondido: a performance que fica no caminho. Em uma operação específica, o retrabalho chega a 62,2% de tempo a mais, número que em sistemas de infraestrutura, bancos de dados ou processamento de rede pode inviabilizar a troca.

O paper também joga luz sobre o limite dos transpiladores automáticos. A tradução preserva a semântica, mas carrega junto hábitos de escrita do C que o compilador de Rust não consegue desfazer sozinho. São padrões de código, não bugs. Por isso passam despercebidos em testes funcionais e só aparecem quando alguém mede tempo de execução.

Impacto

A ferramenta descrita no estudo foi comparada com o Codex, agente de programação de uso geral. Nos 37 casos em que os dois mantiveram a saída do C, a abordagem com regras venceu em 31. Contra a própria variante sem orientação de regras, ganhou em 34 das 41 operações.

A diferença entre os dois resultados importa. O ganho sobre o Codex mostra que um agente genérico, sozinho, não cobre o problema. O ganho sobre a variante sem regras mostra que o valor está no conhecimento codificado sobre os nove padrões de perda de performance, e não apenas no poder de reescrita do modelo. É a diferença entre pedir a um LLM que otimize um arquivo e entregar a ele um diagnóstico do que exatamente quebrou.

O que vem agora

O resumo do paper não informa se a ferramenta será publicada como código aberto, nem detalha prazos para uso em produção. O texto completo está disponível no arXiv, com versão em PDF e HTML experimental, e inclui as referências e as ferramentas de citação associadas à submissão.

O caminho que o estudo sugere para quem já migrou projetos para Rust é o de tratar a tradução automática como primeira etapa, não como entrega final. Falta uma camada de verificação de performance que hoje quase nunca acompanha os processos de migração de código legado.

Fontes

• arXiv cs.AI: Where Does the Performance Go? Understanding and Recovering Performance Regressions in C-to-Rust Translation (https://arxiv.org/abs/2610.23044)