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.
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.
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.
Interesting to see that people are still spending much time on assembly languages :)
I've had a lot of fun with it in recent years as well. (Shameless plug: I've written a few on LLVM integrated assembler regarding better fragments and improving expressions and relocations).
When comparing GNU Assembler and MASM, GAS is missing many features: while loop, string processing (.e.g strlen)
> page 3: "It’s important to understand that MASM converts macro invocation arguments to text values before doing the macro expansion"
Like MASM, GAS uses call-by-name evaluation by default. While GAS's altmacro mode does allow for expression evaluation using syntax like `%(1+2)`, it has strict limitations: it only supports absolute expressions and is restricted to argument positions.
In contrast, MASM's % operator (page 8) looks far more general.
The GNU assembler is not intended to be used by humans, but its goal is to assemble the output of compilers.
On Linux, the "standard" assembler for humans is "nasm", though there are also others.
For anyone writing a non-negligible amount of code in an assembly language it is essential to develop or get from elsewhere a comprehensive library of macros, for avoiding to write huge amounts of boilerplate.
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.