Alguém já usou o gold
linker? Para vincular um projeto bastante grande, tive que usar isso em vez do GNU ld
, que gerava alguns erros e falhava ao vincular.
Como o gold
vinculador é capaz de vincular grandes projetos onde ld
falha? Existe algum tipo de truque de memória em algum lugar?
O
gold
linker foi projetado como um linker específico do ELF, com a intenção de produzir um linker mais fácil de manter e mais rápido do que o BFDld
(o linker GNU binutils “tradicional”). Como efeito colateral, é realmente capaz de vincular programas muito grandes usando menos memória do que BFDld
, presumivelmente porque há menos camadas de abstração para lidar e porque as estruturas de dados do vinculador são mapeadas mais diretamente para o formato ELF.Não tenho certeza se há muita documentação que aborda especificamente as diferenças de design entre os dois vinculadores e seu efeito no uso da memória. Há uma série muito interessante de artigos sobre linkers de Ian Lance Taylor, o autor dos vários linkers GNU, que explica muitas das decisões de design que levaram ao
gold
. Ele escreve que(O segundo linker é BFD
ld
.)O vinculador de ouro foi escrito para tornar o processo de link consideravelmente mais rápido. De acordo com o autor de ouro Ian Lance Taylor
Ele está comparando o desempenho do vinculador de ouro com o vinculador GNU tradicional. gold (ao contrário do vinculador GNU) não usa a biblioteca BFD para processar arquivos de objeto.
A limitação do gold é que (ao contrário do GNU linker que pode processar muitos tipos de arquivos de objetos) ele só pode vincular arquivos de objetos no formato ELF.
Em relação aos problemas que você enfrentou ao usar o vinculador GNU, aqui está uma resposta interessante para uma pergunta semelhante sobre SO de Michael Adam:
gold
vsld
benchmarkPubliquei um benchmark sintético concreto de ld vs gold em: https://stackoverflow.com/questions/3476093/replaceing-ld-with-gold-any-experience/53921263#53921263
Resumo dos resultados: o ouro foi 2x a 3x mais rápido que o ld.
Esse ganho de tempo pode ser um grande divisor de águas em projetos C++ complexos com templates e geração de código fora de controle, pois a etapa de link envolve todos os arquivos do projeto e, diferentemente da compilação, ela deve ser feita sempre, mesmo que você altere apenas um único arquivo .cpp.
Portanto, um tempo de link lento torna o ciclo de desenvolvimento insuportável e provavelmente é a principal razão pela qual o Google afundou recursos nele. Imagine os ganhos de esperar 10s em vez de 30s para cada alteração trivial de arquivo.
Os ganhos de tempo do benchmark sintético também concordaram com os ganhos reais que tive em um projeto complexo do mundo real (gem5), como também mencionado nessa resposta.
Existem três linkers disponíveis em sistemas GNU/Linux modernos:
Para benchmarks de velocidade, consulte: https://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=2 TL, DR:
lld
é mais rápido, seguido porgold
, seguido porld
Algumas fontes dizem que o projeto gold está estagnado , e a estrutura de pacotes no Fedora reflete isso.