krabby: criando um compilador Rust rápido

 (bal-e.org)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Krabby é uma implementação de um compilador Rust do zero com foco em desempenho, criada para melhorar a lentidão de compilação do rustc
  • As melhorias perceptíveis de desempenho no rustc agora tendem a vir de mudanças em APIs e estruturas de dados, e não mais de alterações em funções isoladas; porém, mudanças de grande escala são difíceis por causa do tamanho da base de código e das exigências de estabilidade
  • O Krabby busca, em uma base de código pequena controlada por uma única pessoa e sem priorizar estabilidade, redesenhar em conjunto os componentes do compilador para encontrar novas oportunidades de otimização e uma arquitetura mais coesa
  • O objetivo é testar a hipótese de que, para aumentar significativamente o desempenho de um compilador, é preciso repensar completamente seu design, mesmo em uma linguagem complexa como Rust
  • O código está disponível no repositório krabby no Codeberg, e a meta é publicar o progresso no Fediverse pelo menos a cada 1–2 semanas

Objetivos e contexto do Krabby

  • Rust é a linguagem preferida do autor, mas o compilador rustc é visivelmente lento
  • Muitas pessoas já estão trabalhando para melhorar o desempenho do rustc, e as otimizações perceptíveis obtidas com mudanças em funções isoladas já estão, em grande parte, próximas do limite do que dava para fazer
  • Melhorias realmente significativas agora vêm de mudanças em APIs e estruturas de dados, mas em uma base de código grande como a do rustc, isso se torna praticamente difícil por causa do desenvolvimento simultâneo de vários recursos e das exigências de estabilidade
  • Krabby é uma implementação de compilador Rust do zero com desempenho como prioridade, e seus objetivos são fundamentalmente diferentes dos do rustc
  • Como é uma base de código pequena controlada por uma única pessoa e não prioriza estabilidade, a proposta é projetar todos os componentes considerando como eles se encaixam entre si, buscando novas oportunidades de otimização e uma arquitetura mais coesa
  • O projeto parte da hipótese de que, para melhorar de forma expressiva o desempenho de um compilador, é necessário repensar completamente o design do compilador
  • A ideia é mostrar que otimizações arquiteturais em grande escala podem estar escondidas independentemente da linguagem-alvo, e que isso pode se aplicar não apenas a linguagens simples como C, mas também a linguagens complexas como Rust
  • Mesmo que o design resultante acabe sendo específico para Rust, o processo ainda é visto como valioso pelo que se pode aprender nele

Estado do projeto e materiais públicos

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Lobste.rs

  • Parece que todo mundo quer ter sua própria licença de vaidade https://codeberg.org/bal-e/krabby/…

    • Para um projeto de hobby tudo bem, mas isso acaba sendo um sinal de que este projeto é mais um projeto casual do que algo realmente sério
      Essa licença permite uso e compartilhamento gratuitos para fins pessoais e não comerciais, mas exige que o software derivado também seja compartilhado nas mesmas condições, e para fins comerciais só permite um uso de avaliação por 30 dias
      Fico curioso se o Codeberg exige critérios rígidos de libre/open source para a licença dos projetos. Eu achava que o Codeberg hospedava apenas FOSS, então essa restrição a uso não comercial me surpreendeu, embora eu possa não estar acompanhando bem a situação mais recente
    • Sim, eu sei... já venho pensando bastante sobre a licença há um bom tempo, e estou considerando mudar para a AGPL enquanto ainda estou trabalhando nisso sozinho

  • Rust é grande. Este projeto parece um pouco mais fácil do que “fazer seu próprio navegador”, mas ainda assim não é nem de longe algo fácil. Mesmo assim, valorizo a ambição
    Em krabby: motivations, a velocidade parece ser o principal motivo do projeto
    Pelo que entendo de Rust, verificação de tipos, borrow checking etc. já são bem rápidos, e o gargalo é a geração de código, grande parte disso ligada ao LLVM mais do que ao próprio Rust
    Fico curioso sobre como anda o lado do Cranelift hoje em dia, e se há alguma sobreposição com ideias para acelerar a geração de código

    • Essa premissa assume que toda a estrutura do rustc+LLVM está correta e que agora só importam os fatores constantes
      Pessoalmente, estou bem convencido de que isso não faz muito sentido quando se olha para o pipeline de compilação como um todo. Precisamos de rlib só de MIR e de um backend que permita otimizações de mundo inteiro sem exigir RAM infinita (este comentário)
      “Codegen Unit” é complexidade puramente acidental
    • Depende do que exatamente você está fazendo: Depends on what exactly you're doing
      Em especial, a decomposição detalhada de libraries e binaries pode ser interessante
      O LLVM não é exatamente rápido, mas, se bem me lembro, também não ajudava o fato de o rustc tender a passar para o LLVM uma IR inflada
    • Obrigado :) Parece que há bastante diferença de opinião sobre o tempo de compilação do Rust. Algumas pessoas culpam a verificação de tipos, outras culpam o LLVM
      Minha meta de médio prazo, ou seja, para os próximos uns 5 anos, é o cargo check, então não vou mexer na geração de código
      Ainda assim, acho que ainda há muito espaço para otimização em paralelismo melhor, separação dos hot paths do código de diagnósticos, redução do trabalho duplicado entre verificação de tipos e borrow checking, melhoria do layout de memória das estruturas de dados centrais e assim por diante
      Também ajuda eu ser próximo dos desenvolvedores do rustc e ouvir com frequência sobre vários problemas na base de código
    • O rustc tem um backend Cranelift
    • O LLVM realmente parece ser a parte lenta. Também vi isso nas discussões sobre tempo de compilação do Zig, e a implementação correspondente self-hosted é consideravelmente mais rápida que o LLVM1