Pedido de divórcio do LLVM

 (github.com/ziglang)
2 pontos por GN⁺ 2023-07-01 | 2 comentários | Compartilhar no WhatsApp
  • O projeto Zig tem como meta remover completamente as dependências das bibliotecas LLVM, Clang e LLD do executável principal do Zig
  • O trabalho restante se divide em remover o LLD, eliminar chamadas à API do LLVM, avançar os backends C/x86/wasm/aarch64, remover subcomandos e usos de pré-processador dependentes do Clang, além de implementar um substituto para zig ar
  • O backend LLVM já produz arquivos .bc, mas o compilador Zig deixará de ter a capacidade de compilar .bc em arquivos-objeto, e nesse caso será necessária uma instalação separada do Clang
  • Entre os efeitos esperados estão a simplificação do build a partir do código-fonte e do bootstrap, evitar problemas relacionados a LLVM/Clang/LLD em distribuições Linux e no Homebrew, e reduzir o tamanho do binário de cerca de 150 MiB → 5 MiB
  • A proposta também aponta que o Zig poderá implementar seus próprios passes de otimização e atrair contribuições diretas de projetos de pesquisa como alive2 e de fabricantes de chips como Intel, ARM e RISC-V

Dependências que se quer remover do executável do Zig

  • O objetivo desta issue é remover completamente do projeto Zig as bibliotecas LLVM, Clang e LLD
  • Os pontos de ligação restantes estão organizados nas áreas de LLD, LLVM, Clang e zig ar

Trabalho restante relacionado ao LLD

Trabalho restante relacionado ao LLVM

Trabalho restante relacionado ao Clang

Restrições de zig ar e do tratamento de arquivos .bc

  • zig ar: a drop-in llvm-ar replacement #9828: ainda resta transformar zig ar em um substituto compatível do llvm-ar
  • O backend LLVM já produz arquivos .bc, mas o compilador Zig deixará de ter a capacidade de compilar arquivos .bc em arquivos-objeto
  • Para lidar com esse caso de uso, será preciso instalar o Clang separadamente

Mudanças esperadas com a remoção das dependências

  • Todos os bugs do lado do Zig passarão a estar dentro do escopo de responsabilidade do próprio projeto Zig
  • O processo de compilar o compilador a partir do código-fonte e fazer o bootstrap ficará mais simples, e o sistema hospedeiro precisará ter apenas um compilador C
  • Distribuições Linux e gerenciadores de pacotes como o Homebrew deixarão de lidar com os problemas que criavam em relação a LLVM, Clang e LLD
  • O tamanho do binário do compilador Zig cairá de cerca de 150 MiB para 5 MiB
  • A velocidade de compilação poderá aumentar em várias ordens de grandeza
  • O Zig poderá implementar seus próprios passes de otimização e elevar o estado da arte da computação
  • Poderá atrair projetos de pesquisa como alive2
  • Poderá incentivar contribuições diretas de partes interessadas, como fabricantes de chips Intel, ARM e RISC-V, que querem código de máquina melhor para suas CPUs

Leituras relacionadas

2 comentários

 
alstjr7375 2023-07-02

Será que vai conseguir oferecer otimização e suporte a plataformas no nível do LLVM...
 
GN⁺ 2023-07-01
Opiniões do Hacker News

  • Andrew é uma pessoa extremamente perspicaz, então, agora que isso foi declarado como objetivo, acho que a equipe vai acabar conseguindo
    Mas, do ponto de vista de alguém que não conhece bem as dificuldades do Zig relacionadas ao LLVM, essa decisão parece desviar a capacidade da equipe do próprio Zig para ferramentas periféricas como binutils
    Só pelo título, achei que eles estavam abandonando o compilador, e para um projeto como o Zig parece haver muito a ganhar mantendo o LLVM
    Ainda assim, a ideia de reescrever em Zig boa parte do código dentro do LLVM, em vez de C++, é bem interessante e ambiciosa. Pode até ser vista como tão ambiciosa quanto a tentativa de Lattner, que criou o LLVM
    Mas códigos que por acaso acabam tendo complexidade quadrática serão difíceis de evitar se o Zig se tornar tão popular e útil quanto o LLVM

    • Isso me lembra uma frase que vi há tempos em um texto que parecia ser um documento informal de gerenciamento de projetos da NASA
      A ideia era algo como: “se uma missão espacial não reutiliza um veículo lançador existente, então esse projeto se torna um projeto de desenvolvimento de veículo lançador, e todo o resto que se achava ser o núcleo da missão vira algo secundário”
      Outra parte de que me lembro acrescentava uma premissa como: “embora se possa pensar que criar um veículo lançador adequado a uma missão específica seria mais barato e eficiente do que fazer concessões para se adaptar a um veículo existente”
    • Isso me lembra uma entrevista recente com Chris Lattner sobre o sucesso do Swift. Ele via como fator de sucesso o fato de que, em grandes projetos Objective-C, era possível começar a misturar Swift sem reescrever nada
      Parte do sucesso do Rust também se apoia em uma compatibilidade semelhante com C/C++
      É difícil imaginar o Zig tendo sucesso sem uma capacidade parecida, então espero que eles não sigam em frente com esse marco do jeito que está
    • Há uma grande diferença em relação ao LLVM. Pelo menos no contexto em que a Apple assumiu o projeto, não havia muitas opções
      Isso porque o GCC não queria permitir nem implementar o que a Apple queria ou precisava
    • Não é que tenha sido “declarado como objetivo”. Ainda é uma proposta não aceita
    • binutils está mais para um conjunto genérico de código que lida de forma portável com formatos de código binário, e um compilador não precisa de metade disso, especialmente da parte legada
      Com um foco maior, como no TCC, a maior parte seria geração de código para várias arquiteturas

  • Há dois problemas aqui. Um é a geração de código e o outro é o bootstrapping
    Pela minha experiência, passes de otimização de compiladores são fáceis e divertidos de escrever. Para entender alocação de registradores e a forma SSA é preciso ler artigos, mas dá para escrever de forma divertida o código que faz a IR passar por vários passes de otimização e ir sendo refinada
    É possível criar passes de otimização de alta qualidade sem o LLVM. Mas a etapa de linearizar a IR em código de máquina é um trabalho tedioso e comum, a menos que você goste de todas as formas pelas quais x86-32/64 codifica uma instrução como “mov [eax+8*ebx], 123”
    Se estiver otimizando o tamanho do binário, você vai querer medir em qual plataforma “push eax; push eax; push eax” é mais curto que “add rsp,12”? E isso é só x86; quando multiplicado por arquiteturas não x86 que não importam para a maioria dos desenvolvedores, fica muito maior
    Também é muito provável que bugs grandes em geradores de código para arquiteturas pouco usadas passem anos sem ser descobertos
    O segundo ponto é bootstrapping. Com o que compilar um compilador Zig escrito em Zig? Por exemplo, é possível compilar o compilador Zig com um compilador Zig mínimo, sem otimização, escrito em C
    Mas, se ele não otimiza, será preciso recompilar o compilador Zig novamente com o compilador Zig otimizado. Não é um problema insolúvel, mas um processo de build longo e complexo corre o risco de afastar potenciais contribuidores

  • Depois de promoverem tanto que o Zig consegue compilar C e talvez até C++, parece bem radical agora dizer que vão remover completamente o LLVM
    A menos que muito mais gente participe do suporte, também parece muito improvável que eles cheguem perto do nível de suporte a plataformas do LLVM
    Eu entenderia um plano para adicionar um backend próprio para quem quiser, mas simplesmente remover o LLVM parece precipitado

    • Se o trabalho já tivesse começado, talvez fosse precipitado, mas, como outras propostas no rastreador de issues sem o rótulo “accepted”, por enquanto é apenas uma etapa de solicitar discussão e contrapropostas
      Neste momento, a equipe está coletando feedback, aprendendo quais casos de uso serão afetados e avaliando a viabilidade, então eu diria que é quase o oposto de precipitação
    • Lendo o corpo da issue vinculada, eles não vão eliminar completamente o backend LLVM. Vão apenas separá-lo do binário principal, e, se o LLVM estiver instalado no sistema, ainda será fácil usá-lo como backend
      Faz sentido, porque é meio estranho ter que empacotar uma cópia de 100MB+ do LLVM que nem é necessária no caso comum. Desenvolvedores provavelmente já o terão instalado de qualquer forma em muitos casos
      Porém, pode ser difícil garantir que o Zig instalado funcione corretamente com a versão do LLVM do sistema. Vamos ver
    • Ainda vai emitir bitcode LLVM, mas não vai mais depender das bibliotecas LLVM
      https://github.com/ziglang/zig/issues/13265
    • Eu também entendi exatamente assim
      Recentemente li um pouco mais sobre Zig e também o usei como uma forma fácil de compilar C++ com LLVM sem brigar com pacotes do sistema. A possibilidade de migrar de C/C++ para Zig era um grande argumento de venda
      É algo muito repentino e inesperado. Não sei se é certo ou errado para o projeto, mas, do meu ponto de vista, pareceu realmente surgir do nada
    • Estou usando Zig como compilador C++ em um projeto Rust, porque era a forma menos dolorosa de fazer compilação cruzada no GitHub Actions

  • Por um lado, respeito a disposição cuidadosa de reduzir dependências, mas o custo parece bem sério
    A perda de compatibilidade com C++ basicamente elimina a vantagem que os fãs de Zig ao meu redor mais mencionavam
    A perda de desempenho, ainda que temporária, também é outro ponto central que eles costumavam mencionar junto

    • A maioria das reações parece ser contrária a esta proposta
      Para quem está lendo por alto: isso não é uma decisão tomada, é uma proposta

  • Por cerca de 4 anos, escrevi todos os projetos embarcados e bibliotecas em Zig, e agora várias arquiteturas com suporte tier 1 simplesmente vão sair?
    A linguagem é de vocês, então podem fazer como quiserem, mas, nesse caso, gostaria que ajustassem também o branding de acordo

    • Elas realmente vão sair?
      Acho provável que o suporte tier 1 seja dividido em duas categorias: suporte tier 1 embutido e suporte tier 1 por meio do backend LLVM opcional
      Se uma arquitetura já tem suporte tier 1, não vejo motivo para perder esse suporte só porque o backend LLVM virou uma dependência opcional
      Como Andrew escreveu na proposta, essa abordagem pode ser um caminho para dar suporte melhor a arquiteturas mais raras. Eu trabalharia de bom grado em um backend Zig para uma arquitetura de processador interessante, mas jamais contribuiria com o LLVM. Trabalhar com C++ não é algo para fazer por hobby
    • A ideia é remover o LLVM reimplementando, do próprio jeito, tudo o que o LLVM faz?
      Qual é a vantagem disso? Não é desperdício de recursos?
    • Não é segredo que Zig está antes da 1.0. É difícil colocar essa responsabilidade inteiramente neles, mas ainda assim parece uma proposta bastante radical
    • Por enquanto é só uma proposta. A issue no GitHub também é principalmente um lugar para publicar casos de uso a favor e contra etc., e não está Accepted
    • Isto ainda é uma proposta, então, se um número suficiente de pessoas der opiniões, como muitas já estão fazendo, acho que a equipe core também vai ajustar a abordagem

  • DLang tem 3 compiladores
    gdc é baseado no backend da coleção de compiladores GNU, ldc é baseado no backend LLVM, e dmd é baseado no gerador de código x86 que escrevi para Zortech/Symantec/Digital Mars
    Cada um tem prós, contras e alvos diferentes, mas a linguagem D que eles suportam é a mesma
    No geral, usuários gostam de ter opções, e alguns usam mais de um em conjunto

    • Há uma diferença de abordagem interessante. D parece ter compiladores completamente separados, mas Zig parece caminhar para que o compilador Zig principal dê suporte ao LLVM como backend, se ele estiver instalado
      Se for isso mesmo, gosto da abordagem do Zig
    • Outra linguagem com vários compiladores é Common Lisp. Há em torno de uma dezena de compiladores prontos para produção, alguns comerciais, mas a maioria gratuita
      Isso é muito útil porque permite usar o compilador mais rápido durante o desenvolvimento e, na versão final, usar o compilador com o runtime mais rápido ou o menor uso de memória
      Além disso, quando há uma especificação da linguagem seguida por todos os compiladores, você tem a garantia de que a linguagem é estável e não vai quebrar de repente por baixo
      Claro que também há vantagens em linguagens como Zig, nas quais ainda é possível mudar o que se quiser para tornar a linguagem mais coerente, limpa e poderosa. Hoje em dia passei a valorizar muito mais essa estabilidade, porque ela permite focar em criar valor real para os usuários em vez de ficar correndo atrás das ferramentas de desenvolvimento
    • Ter opções para usuários avançados é uma vantagem, mas acho que ter que escolher em si é uma grande desvantagem
    • Entendo que usuários gostem de opções, mas, se Zig mira adoção ampla no longo prazo, não acho que DLang seja um bom precedente

  • Um dos principais motivos pelos quais Zig era interessante é que ele podia ser encaixado diretamente como alternativa a um compilador C/C++
    No Windows, amigos me disseram que era mais fácil instalar Zig como compilador C/C++ do que qualquer outra alternativa
    Se esta proposta for aceita, pessoalmente acho que a popularidade do Zig cairá para o nível de Hare ou de outras linguagens extremamente de nicho
    Para fazer meus colegas ao menos experimentarem Zig, tive que enviar até um texto dizendo que a Uber o usa em produção. Se ele não tivesse valor imediato em projetos existentes, meus colegas nem pensariam duas vezes
    Ainda assim, entendo o contexto da proposta. O tempo de compilação do LLVM pode parecer horrível, e ter um bytecode próprio permitiria implementar técnicas de otimização legais. Lidar com bugs do LLVM é algo praticamente intocável, e já vi isso acontecer também no ecossistema Julia
    Se minha recomendação tiver algum valor, acho que Zig deveria 1) usar bytecode customizado em builds de debug, para builds rápidos e depuração rápida, e 2) usar LLVM em builds de release, para desempenho rápido em runtime
    Se for possível fazer 1) mantendo o suporte a compilação cruzada de C/C++, por exemplo delegando só essa parte ao LLVM, pode ser o melhor meio-termo, embora haja o trade-off de manter código adicional de backend

    • Como uma das pessoas que lida com bugs do LLVM no ecossistema Julia, digo: sim
      Isso exige um conjunto de habilidades separado do trabalho no compilador Julia de alto nível, e às vezes demora para que correções de bugs sejam integradas upstream
      Mas, na prática, temos uma relação bastante boa e produtiva com o upstream, e, se tivéssemos decidido eliminar o LLVM, o projeto teria realizado muito menos
      Em especial, o suporte a GPU e o suporte a HPC, por exemplo PPC, dependem do LLVM
      Por isso mantemos a posição de que Julia deve ser compilada contra nosso patchset/fork, e não investimos tempo em bugs surgidos em builds de Julia que não usam esses patches. Isso acontece com frequência especialmente em builds de distribuições

  • Tendo acompanhado o trabalho de backends não LLVM em outras linguagens, a proposta linkada passa uma sensação muito forte de arrogância
    Se o autor não fosse quem é, eu teria descartado como uma issue no GitHub escrita de qualquer jeito por um iniciante em Zig
    Ela subestima a quantidade de trabalho necessária, diminui sutilmente todo o trabalho colocado no LLVM, e em cada frase transparece uma confiança e um machismo de “obviamente nós conseguimos fazer mais barato, mais rápido e melhor”. É decepcionante
    Até aqui, eu realmente respeitava o trabalho do Andrew, então tento interpretar com boa-fé que talvez tenha sido escrito às pressas ou de improviso, sem perceber como soaria
    Mas o texto não transmite confiança nem me faz olhar a proposta em si com mais abertura

    • Não sei nada sobre o backend LLVM, mas bibliotecas que tentam resolver 100% dos problemas dos usuários frequentemente acabam difíceis de lidar e lentas em comparação com alternativas mais otimizadas
      Webpack e esbuild são um exemplo disso

  • O momento adequado para criar algo sem LLVM teria sido alguns anos atrás. Mas, se removerem agora as funcionalidades de C++, há uma boa chance de isso ser o fim do Zig
    É surpreendente que, em vez de uma remoção gradual, não tenham anunciado um plano para escrever um compilador C++ próprio em Zig

    • Só escrever um parser de C++ já é um projeto gigantesco
      Nem tenho certeza de que uma pessoa que começasse no 18º aniversário conseguiria escrever um compilador C++. Talvez não sobrasse tempo de vida suficiente para criar um compilador funcional

  • O Zig quer ser o novo C do mundo, não tanto o novo C++ do mundo
    Mesmo nesta proposta, dá para ver que a compilação cruzada de C continuará sendo suportada
    Essa escolha pode estar certa. C é muito usado hoje no mundo de embarcados, e nessa área o LLVM não é bom
    Se eu fosse o Zig, gostaria de mirar todos os microcontroladores, e este é o único caminho realista para conseguir isso