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.
Hm - are the linking requirements for PE and COFF similar enough for that to work?
Mold: A Massively Parallel Linker
21–30 of 31 posts
Re: Mold: A Massively Parallel Linker
#22[dead]
Re: Mold: A Massively Parallel Linker
#23Would 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.
Hm - are the linking requirements for PE and COFF similar enough for that to work?
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.
Re: Mold: A Massively Parallel Linker
#24shameless 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 impleme…
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.
Re: Mold: A Massively Parallel Linker
#25Would 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.
That sounds like you should get in contact with Rui Ueyama. If anybody asks, someone on HN said it seemed like a no-brainer.
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.
Re: Mold: A Massively Parallel Linker
#26Earlier quoted context omitted.
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.
To be clear, Wild also doesn't do incremental linking yet but plans to in the future
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.
Re: Mold: A Massively Parallel Linker
#27This 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…
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 restor…
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.
Re: Mold: A Massively Parallel Linker
#28Earlier quoted context omitted.
The nitter software still works and so do most of the servers except the most popular 2
> 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?
I just set one up but it's not public yet. It was very easy and it just worked.
Re: Mold: A Massively Parallel Linker
#29Earlier quoted context omitted.
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 restor…
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.
> 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.
Re: Mold: A Massively Parallel Linker
#30Wild is a decent bit faster than mold at this point: https://github.com/wild-linker/wild (Benchmarks in the README.)
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 [0] https://www.youtube.com/watch?v=WSHt3-gwVxc
> I’m keen
Told me Australia in two words