Hva er gullkoblingen?

gold linker ble designet som en ELF-spesifikk linker, med den hensikt å produsere en mer vedlikeholdbar og raskere linker enn BFD ld (den «tradisjonelle» GNU binutils linker). Som en bivirkning er den faktisk i stand til å koble til veldig store programmer som bruker mindre minne enn BFD ld, antagelig fordi det er færre lag med abstraksjon å håndtere, og fordi linkerens data strukturer kartlegges mer direkte til ELF-formatet.

Jeg er ikke sikker på at det er mye dokumentasjon som spesifikt adresserer designforskjellene mellom de to linkerne, og deres effekt på minnebruk. Det er en veldig interessant artikkelserie om lenker av Ian Lance Taylor, forfatteren av de forskjellige GNU-linkerne, som forklarer mange av designbeslutningene som fører frem til gold. Han skriver at

Linkeren jeg nå jobber, kalt gull, på vilje være min tredje. Det er utelukkende en ELF-linker. Nok en gang er målet fart, i dette tilfellet å være raskere enn min andre linker. Denne linkeren har blitt betydelig redusert gjennom årene ved å legge til støtte for ELF og for delte biblioteker. Denne støtten ble lappet i stedet for å være designet i.

(Den andre lenken er BFD ld.)

Kommentarer

• ville navnet ' gull ' kommer fra å lese ' ld ' som ' føre ', og gull er åpenbart mer verdifullt enn bly?
• @Aganju Nei, det ' er bare go prefikset til ld.

gulllinker ble skrevet for å gjøre koblingsprosessen betydelig raskere. I følge gullforfatteren Ian Lance Taylor

For øyeblikket har gull bare en betydelig fordel over den eksisterende koblingen: den er raskere. På store C ++ -programmer har jeg målt det som å kjøre fem ganger raskere.

Han sammenligner ytelse med gulllinker med den tradisjonelle GNU-linkeren. gull (i motsetning til GNU linker) bruker ikke BFD-biblioteket til å behandle objektfiler.

Begrensningen av gull er at den (i motsetning til GNU linker som kan behandle mange objektfiltyper) bare kan koble ELF-format objektfiler.

Når det gjelder problemene du møtte når du bruker GNU linker, her er et interessant svar på et lignende spørsmål på SO fra Michael Adam:

Gulllinkeren fant til og med noen avhengighetsproblemer i koden vår, siden den ser ut til å være mer korrekt enn den klassiske med hensyn til noen detaljer. Se f.eks. denne Samba-forpliktelsen.

gold vs ld referanseindeks

Jeg har publisert et konkret syntetisk referanseindeks for ld vs gull på: https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263

Sammendrag av resultater: gull var 2x til 3 ganger raskere enn ld.

Denne tidsgevinsten kan være en enorm spillveksler på komplekse C ++ -prosjekter med ut-av-kontroll maler og kodegenerering, fordi koblingstrinnet involverer alle filer fra prosjektet, og i motsetning til kompilering, må det gjøres alltid, selv om du bare endrer en enkelt .cpp-fil.

Så en langsom koblingstid gjør utviklingssyklusen uutholdelig, og er sannsynligvis hovedårsaken Google sank ressurser i det. Tenk deg gevinsten ved å vente 10-tallet i stedet for 30-tallet for hver trivielle filendring.

Tidsgevinstene for den syntetiske referanseindeksen stemte også overens med faktiske gevinster jeg hadde på et komplekst virkelige verdensprosjekt (gem5), som også nevnt i det svaret.

Det er tre lenker tilgjengelig på moderne GNU / Linux-systemer:

• ld , vedlikeholdt av GNU binutils,
• gull , vedlikeholdt av GNU binutils, «still in beta test»,
• lld , utviklet som en del av LLVM-prosjektet.

For hastighetsmål, se: https://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=2 TL, DR: lld er raskest, etterfulgt av gold, etterfulgt av ld

Noen kilder sier at gullprosjektet har vært stagnerer , og pakkestrukturen i Fedora gjenspeiler dette.