mold 2.0.0 - linker de alta velocidade

• A licença foi alterada de AGPL para MIT, tornando-se a principal mudança do mold 2.0.0
• Corrigido um bug que impedia a criação de arquivos-objeto com mais de 65520 seções ao usar --relocatable
• -undefined agora é interpretado como sinônimo de --undefined, e não de -u ndefined, alinhando-se ao comportamento dos linkers GNU e do LLVM lld
• -nopie passa a ser tratado como sinônimo de --no-pie
• Suporte aos tipos de relocação R_RISCV_SET_ULEB128 e R_RISCV_SUB_ULEB128 em RISC-V
• Suporte ao tipo de relocação R_PPC64_REL32 em PPC64

[GN⁺]

Comentários no Hacker News

• mold é um trabalho realmente excelente em sistemas modernos.
  Recentemente, ao tentar acelerar o build de um projeto, percebi que a etapa de linkedição era um gargalo enorme. Mesmo usando 24 núcleos * 2 threads, cerca de 30% do desempenho total ficava ocioso por causa do linker.
  Eu já tinha tentado compilar com mold antes, mas na época não funcionou bem; pretendo tentar de novo.

  • Mold é incrível. Alguns meses atrás, enquanto mexia no O3DE, troquei para o Mold para ver se conseguia reduzir o ciclo build-execução, e ficou claramente mais rápido.
    Não lembro os números exatos, mas era uma diferença bem grande, do tipo algo que levava alguns segundos com gold e lld cair para menos de 1 segundo com mold.
  • Na empresa também fizemos algumas provas de conceito, e em uma máquina pequena de build de testes o tempo total de build da camada de UI caiu de 44–45 minutos para 29 minutos ao trocar lld por mold.
    Era um código C++/Qt complexo.
  • mold -run ninja funciona muito bem no meu ambiente.

• Fico muito feliz em ver a notícia da mudança de licença. Espero que o projeto também consiga gerar receita, mas com uma licença MIT a chance de integrá-lo em projetos de trabalho fica muito maior.
  Se acabarmos usando de fato, pretendo tentar convencer a empresa a patrocinar este projeto.

  • A licença de um linker não deveria importar muito. Ele não injeta código protegido por copyright e, mesmo no ecossistema GPL, já há precedentes de tratar boilerplate trivial como exceção, então não há motivo para o binário gerado ser afetado pela licença copyleft da ferramenta.
    A AGPL também só imporia restrições ao distribuir um linker modificado privadamente como serviço de rede, o que não é um cenário realista para uma ferramenta básica de desenvolvimento.

• Fiquei curioso sobre a mudança de licença. Isto não é um executável? Chamar um processo separado não obriga o software que o chama a virar GPL, então, no caso comum, a mudança para MIT não deveria ter impacto.
  Se os autores realmente quisessem uma licença mais permissiva, em vez de relicenciar de AGPL para MIT, deveriam ter mudado para AGPL com uma exceção de linkedição. Um exemplo de projeto GPL com exceção de linkedição é o libgit2: https://github.com/libgit2/libgit2#license
  Esse tipo de licença é mais permissivo e, ao mesmo tempo, ainda permite vender licenças comerciais para quem cria alterações de código fechado.

  • Acho que o ponto central é que os autores não querem mais continuar vendendo licenças. Parece que não valia a pena pelo trabalho que dava.
    A versão para macOS, sold, parece ser uma exceção.

• Este linker aumentou de forma perceptível a satisfação no desenvolvimento no meu repositório Rust exploratório, que está virando um grande monólito web usando SeaORM e axum/tokio.
  Você não vai querer saber o tamanho do meu diretório target, mas os builds incrementais ficaram muito mais ágeis.

  • Preciso brincar um pouco com mold.
    15:55 $ du -Hs --si target/
11G target/

• Mold é excelente, e tenho alguns usos favoritos para ele.

  1. Builds em Rust ficam mais rápidos.
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. No ArchLinux, adicionar "-fuse-ld=mold" ao CFLAGS também acelera o makepkg.
  • Existe alguma forma de sobrescrever essa configuração de linker apenas na instalação local? Não quero mudar o código de produção nem os binários, mas seria bom se os builds ficassem mais rápidos.
  • Fiquei curioso para saber quanto o tempo de linkedição em Rust mudou antes e depois.
  • Como esta versão mais recente se compara ao lld? Também roda em alpine/musl?

• Uma decisão muito sensata. Às vezes há momentos difíceis em que preciso admitir que algumas coisas nos meus produtos ou código não são adequadas para monetização.
  É o mercado que diz isso e, infelizmente, em vez de lutar contra ele, é importante encontrar outra coisa que o mercado recompense.

• Alguém sabe se essa mudança de licença/estratégia de negócios também será aplicada ao sold? O sold é o mold para macOS.
  https://github.com/bluewhalesystems/sold

  • A Apple tem um novo linker paralelo, que talvez seja interessante — ou talvez não.
    https://twitter.com/davidecci/status/1665835119331135488
  • Olhando o topo do README do mold, meu palpite é que ele não vai se tornar open source.
    “Este repositório contém a versão gratuita do linker mold. Se você procura uma versão comercial com suporte a macOS, visite o repositório do linker sold.”
  • Não entendo por que a Apple não patrocina este projeto para torná-lo o linker padrão do Xcode.
    Bastaria pagar bem pelo trabalho e tornar o mundo melhor.
    Para a Apple, isso seria fácil demais.

• A licença mudou de AGPL para MIT.
  Mas como artesãos tão excelentes deveriam ser recompensados, e por que isso ainda não acontece? Acho que empresas, independentemente do tamanho, deveriam reservar algum orçamento para dependências ou ferramentas essenciais e divulgar isso em seus sites oficiais. Parece que precisamos de mais uma espécie de norma cultural.

• Eu tinha esquecido que isto era um linker rápido
  “O Mold 2.0.0 é o novo lançamento major do nosso linker de alta velocidade. Nesta versão, mudamos a licença de AGPL para MIT com o objetivo de ampliar a base de usuários. Quem acompanhou o progresso sabe que não foi uma decisão fácil, pois vínhamos tentando monetizar o produto com um modelo de licença dupla AGPL/licença comercial. Infelizmente, essa abordagem não correspondeu às expectativas. A mudança de licença é resultado de aceitarmos essa realidade. Não queremos continuar insistindo em uma estratégia que não estava funcionando bem.”

  • Alguém se lembra da época em que era preciso pagar pelo cc no Solaris? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    Era horrível, e também uma péssima forma de tratar desenvolvedores que escreviam software para o seu próprio SO
    Há muito tempo estamos acostumados a não pagar por ferramentas de desenvolvimento de baixo nível e, em vez disso, pagar por suporte. É surpreendente que tenham tentado uma licença desse tipo

• Ao longo dos anos vi várias discussões sobre linkers rápidos e relatos de que trocar um linker por outro mais rápido reduziu bastante o tempo de compilação, mas em geral eu não entendia bem por que linkers são lentos
  Seria bom se alguém pudesse explicar

  • Não é uma explicação completa, mas a linkedição é intensiva em CPU, e linkers antigos em geral são single-thread
    Uma boa parte do ganho de desempenho vem de processar o trabalho em paralelo, o que leva a uma grande melhoria em CPUs modernas, potentes e multicore
    Se quiser saber mais, há uma boa apresentação do Rui sobre o Mold: https://www.youtube.com/watch?v=hAt3kCalE0Y
  • No caso ideal, um linker deveria ser tão rápido quanto cat. Afinal, bastaria concatenar os binários e pronto. Na época dos discos giratórios, a E/S de disco era um problema, mas hoje é menos
    O que leva tempo é reescrever conteúdo durante o processo. Percorrer a tabela de relocação e inserir endereços no código é barato, e o dead stripping por seção também é razoavelmente barato, mas fazer dead stripping de blocos básicos individuais dentro de uma função exige muito mais análise e consome tempo
    Deduplicar strings constantes é uma boa ideia, mas é preciso despejar tudo em alguma forma de tabela hash. Se você quiser compartilhar também sufixos comuns, o trabalho aumenta ainda mais
    Deduplicação, dead stripping e reescrita de informações de depuração também levam tempo. Builds de debug podem conter vários GB de DWARF que precisam ser reescritos
    Curiosamente, o fato de o linker ser scriptável e aceitar um programa para interpretar não parece ter um custo grande. Provavelmente porque esses scripts são bem curtos e suas funcionalidades são um tanto limitadas
    Historicamente, o motivo de o lld ser muito rápido era que ele fazia pouca manipulação de informações de depuração ou outras deduplicações. O lld rodava rápido, mas o binário de saída ficava grande
    Faz alguns anos que me afastei da área de desempenho de linkedição, então não sei bem qual é o estado atual. Em especial, não sei onde mold ou lld se situam hoje no equilíbrio entre qualidade da saída e desempenho próprio
  • O melhor material que li foi o blog do Ian Taylor sobre o trabalho dele no linker gold
    https://www.airs.com/blog/archives/38
    “Mais uma vez, o objetivo é velocidade. Neste caso, ser mais rápido que meu segundo linker. Esse linker ficou consideravelmente mais lento ao longo dos anos com a adição de suporte a ELF e bibliotecas compartilhadas. Esse suporte não foi projetado desde o início; foi acrescentado depois. Os planos futuros para o novo linker também incluem suporte a linkedição incremental, que é outra forma de aumentar a velocidade.”
    Pense nos apps dos primórdios do Unix. Eram apps simples, de propósito único, provavelmente com um único arquivo-fonte, um único objeto, linkando apenas com a libc, sem nada como bibliotecas compartilhadas
    Depois disso, recursos “obrigatórios” foram sendo adicionados, e o código do linker cresceu organicamente. Especialmente na época em que discos giratórios eram o gargalo, a correção dos recursos era mais importante que a velocidade