Wat is de gouden linker?

De gold linker is ontworpen als een ELF-specifieke linker, met de bedoeling een beter onderhoudbare en snellere linker te produceren dan BFD ld (de “traditionele” GNU binutils linker). Als neveneffect is het inderdaad in staat om zeer grote programmas te koppelen die minder geheugen gebruiken dan BFD ld, vermoedelijk omdat er minder abstractielagen zijn en omdat de gegevens van de link structuren worden directer toegewezen aan het ELF-formaat.

Ik weet niet zeker of er veel documentatie is die specifiek ingaat op de ontwerpverschillen tussen de twee linkers en hun effect op het geheugengebruik. Er is een zeer interessante serie artikelen over linkers door Ian Lance Taylor, de auteur van de verschillende GNU-linkers, die veel van de ontwerpbeslissingen verklaart die leidden tot gold. Hij schrijft dat

De linker die ik nu werk, genaamd goud, zal wees mijn derde. Het is uitsluitend een ELF-linker. Nogmaals, het doel is snelheid, in dit geval sneller dan mijn tweede linker. Die linker is in de loop der jaren aanzienlijk vertraagd door ondersteuning voor ELF en voor gedeelde bibliotheken toe te voegen. Deze ondersteuning is gepatcht in plaats van ontworpen.

(De tweede linker is BFD ld.)

Reacties

• zou de naam ' goud ' komen uit het lezen van ' ld ' als ' lead ', en goud is duidelijk waardevoller dan lood?
• @Aganju Nee, het ' is gewoon go voorafgegaan door ld.

De gold linker werd geschreven om het linkproces aanzienlijk sneller te maken. Volgens de goudauther Ian Lance Taylor

Op dit moment heeft goud er maar één aanzienlijk voordeel ten opzichte van de bestaande linker: het is sneller. Bij grote C ++ -programmas heb ik gemeten dat het vijf keer sneller draait.

Hij vergelijkt de prestaties van de Gold Linker met de traditionele GNU-linker. gold (in tegenstelling tot de GNU-linker) gebruikt de BFD-bibliotheek niet om objectbestanden te verwerken.

De beperking van gold is dat het (in tegenstelling tot GNU Linker die veel objectbestandstypen kan verwerken) alleen objectbestanden in ELF-formaat kan koppelen.

Met betrekking tot de problemen waarmee je te maken kreeg bij het gebruik van GNU linker, hier is een interessant antwoord op een vergelijkbare vraag over SO van Michael Adam:

De gouden linker vond zelfs enkele afhankelijkheidsproblemen in onze code, aangezien deze met betrekking tot enkele details correcter lijkt te zijn dan de klassieke. Zie b.v. deze Samba-commit.

gold vs ld benchmark

Ik heb een concrete synthetische benchmark van ld vs gold gepubliceerd op: https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263

Samenvatting van resultaten: goud was 2x tot 3x keer sneller dan ld.

Deze tijdwinst kan een enorme game-wisselaar zijn bij complexe C ++ -projecten met oncontroleerbare sjablonen en codegeneratie, omdat de linkstap alle bestanden omvat van het project, en in tegenstelling tot compilatie, moet het altijd worden gedaan, zelfs als u slechts één .cpp-bestand wijzigt.

Dus een langzame verbindingstijd maakt de ontwikkelingscyclus ondraaglijk, en is waarschijnlijk de belangrijkste reden Google heeft er middelen in gestopt. Stelt u zich eens de voordelen voor van 10 seconden wachten in plaats van 30 seconden voor elke triviale bestandswijziging.

De tijdwinst van de synthetische benchmark kwam ook overeen met de daadwerkelijke winst die ik had op een complex real-world project (gem5), zoals ook vermeld in dat antwoord.

Er zijn drie linkers beschikbaar op moderne GNU / Linux-systemen:

• ld , beheerd door GNU binutils,
• gold , beheerd door GNU binutils, “nog in bètatest”,
• lld , ontwikkeld als onderdeel van het LLVM-project.

Zie voor snelheidsbenchmarks: https://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=2 TL, DR: lld is de snelste, gevolgd door gold, gevolgd door ld

Sommige bronnen zeggen dat het gouden project is stagneert , en de pakketstructuur in Fedora weerspiegelt dit.