Here's a lwn.net link to Ian Lance Taylor's blog posts about his gold linker (his blog doesn't seem to have any table of contents or group the linker-related blog posts in one area/tag).
But back in the late 2000s, the blog posts were a combination of algorithm optimization class and software history since no one seemed to step up to cleanup the technical debt that GNU ld had accumulated over the decades.
shameless plug: lld 23.x is significantly faster than 22.x! I wrote about the optimizations in https://maskray.me/blog/2026-04-12-recent-lld-elf-performanc...
As a side note, parallel input file parsing and symbol resolution aren't a silver bullet. I have an experimental branch (net ~800 lines of code) adding this to lld/ELF, but it actually loses performance when restricted to --threads={1,2}
I read how mold implements parallel input file parsing a while ago. It is overly complicated. wild's model seems superior.
---
"Table 4." in the paper feels misleading to me. I have never measured such high speedups. In addition, on debug builds (especially --gdb-index builds), mold's edge over lld is smaller.
On ICF, some unknown fraction of mold's speedup is due to "doesn't do the symbol bootkeeping". The symbol tables are different in mold but identical in lld.
rui314 17 hours ago [-]
Table 4 shows actual measurements on my Threadripper 7980X machine, so I'm not sure whether the numbers look too good or not. I chose large programs more or less at random as the test set without thinking too much about it, so they were not cherry-picked. I'm developing mold on this machine, so mold may naturally be optimized for this configuration. That's why we have Table 6. My benchmark is available at https://zenodo.org/records/21882261. It's pretty easy to run, so you may want to try it out.
NobodyNada 15 hours ago [-]
Whoa, it's MaskRay! Your blog has been a lifesaver for me every time I've needed to understand some obscure detail about linker behavior. Thanks a ton for all your work in this area, and thanks even more for writing about it.
gabeochoa 1 days ago [-]
Old tweet from Rui, but I saw it in a recent zig video and really liked the sentiment:
> my strategy is to increase the value of commons by, say, 100 and get 1 as a return, so bear with me. If you want to use mold for free, you can just do that. This is my open-source business strategy.
Wishing the best for Mold and Rui
_jackdk_ 1 days ago [-]
Given the passing of nitter, xcancel, etc., thank you for quoting the relevant text.
inigyou 1 days ago [-]
The nitter software still works and so do most of the servers except the most popular 2
tome 23 hours ago [-]
> so do most of the servers except the most popular 2
Are you sure? All three servers I regularly use, as well as all of the mirrors that I found with a quick search, are down. If there are other servers still working then can you please give a hint about how I could find them?
inigyou 16 hours ago [-]
I just set one up but it's not public yet. It was very easy and it just worked.
account42 21 hours ago [-]
xcancel.com and nittler.poast.org were the only remaining servers that worked reliably for me before the cease&desist.
dochtman 1 days ago [-]
Wild is a decent bit faster than mold at this point:
I'm keen to follow along with Wild as their intent is to be incremental, and Zig recently announced incremental linking support. I'm also a fan as its cool to seen an Australian working full time on open source (I'm also Australian)
Edit to add: I think David's talk on Wild [0] is an interesting summary of what a linker is and why its hard to make incremental
Seems that some optimizations went to mold 2.42 and others are not yet released. Wild benchmarked mold 2.40 or 2.41
elygre 1 days ago [-]
I guess this sentence from the Wild readme is also relevant:
Mold is already very fast, however it doesn't do incremental linking and the author has stated that they don't intend to.
jakkos 24 hours ago [-]
To be clear, Wild also doesn't do incremental linking yet but plans to in the future
rui314 16 hours ago [-]
I think the way I've talked about incremental linking may have given a somewhat misleading impression. I'm not against incremental linking, and I'm not denying its possible usefulness. But especially when I was developing lld, I felt that we should focus first on speeding up full links.
Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?
In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.
Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.
peter_d_sherman 1 days ago [-]
Excellent (pardon the pun!) link! :-)
omoikane 1 days ago [-]
This is a wonderful paper that includes many optimization tricks that are generally applicable, including various optimizations that they retrofitted into lld. But I thought there was one meta optimization that was especially interesting (from page 2):
> A new linker's early adopters knowingly accept such differences, which is one reason why drastic improvements tend to come from new linkers rather than existing ones
This is true of many things, not just linkers. I think this is encouraging for people to (re)try things that have already been done, because newcomers are allowed to take risks that established things can't take.
matheusmoreira 1 days ago [-]
Mold's definitely innovating.
I use mold a lot for code embedding in my lisp. I needed extra null PHT entries in the ELF so I could easily patch in custom segments into the interpreter after the link was done.
GNU pretty much ignored the feature request and LLVM probably never even saw the issue, but Rui shipped the --spare-program-headers feature pretty much immediately after I requested it and it immediately restored my sanity.
Current version of my patcher supports ld and lld, but it has to move the PHT to the end of the file in order to append the new segments. Mold is still the only way to avoid the ugly hole where the PHT used to be.
inigyou 16 hours ago [-]
FYI you aren't supposed to use an OS-specific header type, since you aren't the OS. No one can stop you, of course, and since there isn't an application-reserved range, you had to pick someone's reserved range.
matheusmoreira 16 hours ago [-]
> since you aren't the OS
Says who? You make it sound like there's some authority out there assigning these numbers. It's not like GNU had to go out there and beg them for it. They just did it, and the world just had to cope.
Also, I'm building lone directly on top of the Linux kernel. That absolutely makes me the "operating system", in the GNU and POSIX sense. Lone/Linux, if you will. The idea is to take this far enough to boot Linux into a custom lisp userspace.
inigyou 14 hours ago [-]
[dead]
lrvick 1 days ago [-]
We use mold as the default linker in the Stagex linux distribution. It shaved hours off our full tree build time.
mbrumlow 1 days ago [-]
Would use this at a fairly large company if we had windows and Mac support, probably could get budget to pay for the features it’s missing.
ahartmetz 1 days ago [-]
That sounds like you should get in contact with Rui Ueyama. If anybody asks, someone on HN said it seemed like a no-brainer.
DannyBee 17 hours ago [-]
Absolutely. Rui is awesome. He's always been awesome. I was his director and then vp for a long time (also replaced by awesome people, thankfully). The day he left to make a go of mold and such I was sad for us and super excited for him.
pjc50 21 hours ago [-]
Hm - are the linking requirements for PE and COFF similar enough for that to work?
rurban 19 hours ago [-]
No. I wrote my integrated linkers with rcc for pe/coff, elf and macho by myself, and macho was the worst to be dealt with. elf was pretty easy, easier than pe/coff.
Mine is also much faster than mold/wild, because I do much less work, and I have all the objects already in memory. Similar to tinycc. Only when someone needs a very unusual unsupported linker feature, I have to fallback to an external linker, which is ~100x slower. The less work it has to do, the faster. I dont appreciate the unix habit to use intermediate files all along, which needs additional readers and writers.
forest_brothers 10 hours ago [-]
[flagged]
hiteshisoni 20 hours ago [-]
[dead]
Rendered at 06:10:18 GMT+0000 (Coordinated Universal Time) with Vercel.
see https://lwn.net/Articles/276782/
GNU gold is deprecated and will probably be removed soon. ( https://www.phoronix.com/news/GNU-Gold-Linker-Deprecated )
But back in the late 2000s, the blog posts were a combination of algorithm optimization class and software history since no one seemed to step up to cleanup the technical debt that GNU ld had accumulated over the decades.
I read how mold implements parallel input file parsing a while ago. It is overly complicated. wild's model seems superior.
---
"Table 4." in the paper feels misleading to me. I have never measured such high speedups. In addition, on debug builds (especially --gdb-index builds), mold's edge over lld is smaller.
On ICF, some unknown fraction of mold's speedup is due to "doesn't do the symbol bootkeeping". The symbol tables are different in mold but identical in lld.
(https://x.com/rui314/status/1560277403787997185)
> my strategy is to increase the value of commons by, say, 100 and get 1 as a return, so bear with me. If you want to use mold for free, you can just do that. This is my open-source business strategy.
Wishing the best for Mold and Rui
Are you sure? All three servers I regularly use, as well as all of the mirrors that I found with a quick search, are down. If there are other servers still working then can you please give a hint about how I could find them?
https://github.com/wild-linker/wild
(Benchmarks in the README.)
Edit to add: I think David's talk on Wild [0] is an interesting summary of what a linker is and why its hard to make incremental
[0] https://www.youtube.com/watch?v=WSHt3-gwVxc
Told me Australia in two words
Seems that some optimizations went to mold 2.42 and others are not yet released. Wild benchmarked mold 2.40 or 2.41
Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?
In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.
Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.
> A new linker's early adopters knowingly accept such differences, which is one reason why drastic improvements tend to come from new linkers rather than existing ones
This is true of many things, not just linkers. I think this is encouraging for people to (re)try things that have already been done, because newcomers are allowed to take risks that established things can't take.
I use mold a lot for code embedding in my lisp. I needed extra null PHT entries in the ELF so I could easily patch in custom segments into the interpreter after the link was done.
GNU pretty much ignored the feature request and LLVM probably never even saw the issue, but Rui shipped the --spare-program-headers feature pretty much immediately after I requested it and it immediately restored my sanity.
https://www.matheusmoreira.com/articles/self-contained-lone-...
Current version of my patcher supports ld and lld, but it has to move the PHT to the end of the file in order to append the new segments. Mold is still the only way to avoid the ugly hole where the PHT used to be.
Says who? You make it sound like there's some authority out there assigning these numbers. It's not like GNU had to go out there and beg them for it. They just did it, and the world just had to cope.
Also, I'm building lone directly on top of the Linux kernel. That absolutely makes me the "operating system", in the GNU and POSIX sense. Lone/Linux, if you will. The idea is to take this far enough to boot Linux into a custom lisp userspace.
Mine is also much faster than mold/wild, because I do much less work, and I have all the objects already in memory. Similar to tinycc. Only when someone needs a very unusual unsupported linker feature, I have to fallback to an external linker, which is ~100x slower. The less work it has to do, the faster. I dont appreciate the unix habit to use intermediate files all along, which needs additional readers and writers.