Rust adota geração de código com Cranelift

• Cranelift é um backend de geração de código sob licença Apache-2.0, desenvolvido como parte do runtime Wasmtime para WebAssembly
• Em outubro de 2023, o projeto Rust começou a oferecer o Cranelift como um componente opcional da toolchain nightly
• Agora, os usuários podem usar o Cranelift como backend de geração de código para builds de depuração de projetos escritos em Rust
• O Cranelift concorre com compiladores existentes e gera código mais rapidamente graças a um design simplificado que prioriza apenas otimizações importantes

A importância do tempo de compilação

• Usuários de linguagens de programação querem tempos de compilação rápidos
• Assim como outras linguagens que usam LLVM, Rust também recebeu reclamações sobre o tempo de compilação
• Um compilador que gere código com rapidez suficiente pode ser mais vantajoso do que usar um interpretador
• Um compilador focado em velocidade de compilação pode ter grande valor

As otimizações do Cranelift

• O Cranelift realiza otimizações de várias formas durante a geração de código
• O pipeline de otimização é baseado em E-graphs, uma estrutura de dados que representa de forma eficiente conjuntos de representações intermediárias
• Em compiladores tradicionais, a ordem das otimizações afeta fortemente a qualidade do código gerado
• O Cranelift usa E-graphs para que a ordem das otimizações não afete o resultado
• Extrair a representação final de um E-graph é um problema NP-completo, mas o Cranelift usa heurísticas para extrair rapidamente uma representação boa o suficiente

Cranelift para Rust

• Foi necessário um esforço considerável para usar o Cranelift como backend do Rust
• O compilador Rust usa uma IR de nível intermediário para representar programas com checagem de tipos
• Para usar o Cranelift, foi necessária uma biblioteca que convertesse essa IR de nível intermediário em CLIF
• Essa biblioteca foi escrita principalmente por "bjorn3", membro da equipe do compilador Rust
• Os usuários podem testar o backend Cranelift usando rustup e cargo

Opinião do GN⁺

• A adoção do Cranelift pode ser vista como uma resposta à demanda contínua da comunidade Rust por tempos de compilação menores. Isso pode contribuir para aumentar a produtividade dos desenvolvedores.
• A abordagem do Cranelift para resolver o problema da ordem das otimizações com o uso de E-graphs apresenta um novo paradigma no design de compiladores. Isso pode indicar novos rumos para pesquisa e desenvolvimento de compiladores.
• De um ponto de vista crítico, ainda é necessário validar, por meio de mais casos reais de uso, o quão estável e eficiente o Cranelift é em comparação com o LLVM.
• Outros backends de compilador com funções semelhantes ao Cranelift incluem o libgccjit do GCC, e comparações com essas alternativas podem ajudar a entender com mais clareza os pontos fortes e fracos do Cranelift.
• Desenvolvedores que adotarem o Cranelift devem considerar a compatibilidade com a infraestrutura existente baseada em LLVM e os custos de transição, além de avaliar cuidadosamente o desempenho e a estabilidade do Cranelift.

[GN⁺]

Opiniões no Hacker News

• O backend e a otimização podem ser usados de forma diferente para crates distintos. Para dependências, muitas vezes faz sentido usar um build LLVM otimizado e, para o próprio código, usar LLVM em modo debug ou Cranelift.
• Um artigo que oferece uma ótima visão geral sobre velocidade de otimização versus qualidade da otimização. Em particular, a compilação copy-and-patch que usa código pré-compilado ainda é a mais rápida, mas tem menos espaço para otimizações. O Cranelift usa e-graphs para representar equivalência no IR, permitindo mais otimizações do que a abordagem copy-and-patch. A saída mais otimizada provavelmente continuará vindo de toolchains tradicionais de compilação como LLVM ou GCC, mas, para usuários que querem obter uma saída "rápida o suficiente" o mais cedo possível, novas técnicas de compilador oferecem uma alternativa promissora.
• Há muitos comentários sobre builds debug completos, mas acho que a diferença mais importante é o tempo de build incremental para pequenas mudanças. É isso que acelera a iteração no desenvolvimento. Ao comparar os tempos de build depois de pequenas alterações no rust-analyzer e no projeto gleam, adicionar Cranelift e mold mostrou melhorias muito maiores. Mesmo em comparação com o Terraform, compilado em Go, isso mostra uma grande melhoria no Rust.
• No momento não há suporte para Macs M1-M3, e parece que também não há suporte para Windows. A atualização mais recente do colaborador mais ativo termina de forma ambígua. O suporte a Windows foi omitido por enquanto, e no macOS há suporte apenas para x86_64. Se você usa um processador M1, pode tentar instalar a versão x86_64 do rustc e usar o Rosetta 2, mas o Rosetta 2 pode afetar o desempenho, então vale comparar com o backend LLVM.
• No projeto Bevy, tentaram seguir as instruções do artigo e compararam com um build "normal". O build de release pareceu mais rápido do que o build Cranelift+debug, mas isso foi por causa do cache com sccache e um NAS local. Ao testar novamente apenas o build debug sem cache, o tempo de compilação caiu quase pela metade.
• Descobri o ESC/Java pelo link sobre Equality Graphs. Fico curioso se alguém realmente já tentou usar o ESC/Java ou teve sucesso com ele. Seria interessante comparar com o Spot bugs, antes conhecido como Findbugs.
• Estou muito animado com a possibilidade de builds debug com Cranelift acelerarem a iteração no desenvolvimento. Isso é especialmente importante em Rust para WASM/frontend, onde a velocidade de iteração importa, e a nova era das ferramentas Rust às vezes entrega builds abaixo de 1 segundo. Como ainda não há suporte para ARM no macOS, usuários de M1-M3 vão ter que esperar um pouco.
• Fico curioso se existem benchmarks de runtime com Cranelift, e não de tempo de compilação. O artigo menciona "duas vezes mais lento", mas esses dados são de 2020. Gostaria de saber se houve uma melhora significativa desde então.
• Gostaria de saber se alguém consegue explicar por que se espera que o Cranelift seja mais rápido que o LLVM e por que essas melhorias não poderiam ser aplicadas também ao LLVM.