Mold/macOS is 11 times faster than the Apple's default linker to link Chrome
twitter.com
twitter.com
If not, any plans to support this in the future? :)
But even without multi-threading, mold is still faster than other linkers. I can think of various reasons why, but I don't know which attributes how much. I believe the biggest contributor is its efficient data structure -- it is hard to make program faster by writing fast code, but it can naturally be achieved by designing efficient data structures. That said, it is hard to compare two or more programs to find out why one program is faster than the others unless their designs are similar.
My assumption is that future machines will have more cores than we have today on average, so I'm optimizing mold for such computers.
From the manpage of mold-1.3.0, I get the impression mold is designed to scale up to 32 cores, but not more.
man mold | rg -C2 32
--threads
--no-threads
Use multiple threads. By default, mold uses as many threads as the number of cores or 32, whichever is the smallest. The reason why it is capped to 32 is because mold doesn't scale well beyond that point. To use only one thread, pass --no-threads or --thread-count=1.
Thanks for the great write up as well as mold itself!
We use lld currently but had to disable threading as sometimes in CI several of our test binaries would get linked at the same time. Whenever this happened the lld instances appear to have spawned enough threads to overload our Jenkins slave to the point that the master wasn't able to reach it and failed the build.
Unfortunately GNU Make offers no such mechanism. And for Ninja build generation I don't think Meson does it either.
Thanks for your good work! I still remember the O(n^2) complexity of ld.bfd when linking C++ code.
I know this is a type, but it is interesting to see knowledge as a score or commodity you can "earn".
( ͡° ͜ʖ ͡°)
"mold is a faster drop-in replacement for existing Unix linkers. It is several times faster than the LLVM lld linker, the second-fastest open-source linker which I originally created a few years ago. mold is designed to increase developer productivity by reducing build time, especially in rapid debug-edit-rebuild cycles."
I don't understand how things like this still manage to front-page without a cursory explanation.
Also, thank you for finding out what the topic discussion was about and sharing. I couldn't infer the meaning.
The intention is just to comb through the stacks looking for good stories that didn't get attention the first time around—especially on topics that aren't correlated with anything else. HN has a wealth of these and I'm pretty sure we still miss half of them.
I find myself defaulting to Linux for Rust development these days, mostly because Mold makes the inner loop of development so much faster.
( I hope more US companies are opened to truly remote )
*in the US.
In my country, those salaries are completely unheard of.
I live in the UK and dev salaries are maybe half of the US, but people don't leave in droves because there are other factors - family, friends, quality of life, effort of moving your life across continents, etc.
Look at Sidekiq for inspiration on how to charge for open source.
> This is also a bit unusual business model because mold can be used for free.
You're selling the copyright, right? That's ok - businesses pay for stuff like this. Although I wonder if instead you'd be better off if you created a corporation and instead offered to sell the company's IP + your commitment to support the work over ~1-2 years. This might be a more common scenario for M&A teams to work with. Especially if you are keen on supporting more target architectures/OSs. Someone like ARM or SiFive or FAANG would easily shell out that kind of money to get mold.
Basically, I think your best chance of generating interest from this is the bottom-up (since the individual engineers are the ones who would be feeling the pain that this could help solve), but I'm not really sure ICs at the companies large enough to be potential customers for this have any likely path forward with the way you've structured things right now. I'm not sure if you're flexible on this at all, and obviously I can't guarantee we'd get anywhere, but if you're interested in hearing more details about the potential use my team (and probably a number of other teams at my company would be able to make use if we were able to work something out), feel free to email me! Any prefix @<my username>.com will forward to my gmail.
Building the software is divided into two steps; compiling your source files into object files, then linking those object files together into an executable. As a project grows, the time taken by the compile step in this development loop stays roughly constant; if you only change a single source file, only that source file has to be recompiled. However, the link step has to link together all your object files, from scratch, every time, so the time taken by the link step grows roughly linearly as the project size grows.
Since mainstream linkers are fairly slows, an incremental build of huge projects is generally dominated by the link step. I've personally experienced the pain of making a small change to Chromium, waiting a second or so for the source file I changed to be recompiled, then waiting a minute or two for the linker to go through every single object file and produce the final executable. Mold would have reduced the build time in the development loop from minutes to seconds.
I hope that helped.
Similarly I had to replace how we implement C runtime destructors because Apple deprecated the way to write a destructor in a binary. This wasn't too hard to do, just call atexit from the itanium C++ ABI, but we had basically no warning as far as I'm aware.
Does someone have a source explaining the state of the art? With all the different compilers, gcc, clang and the different flavours of linkers: ld, lld, mold, gold, ?
No. Linkers today even do link-time code generation. Debug info is gargantuan and can be kept as separate files too.
Those explicit directives might be more implicit than you think. A linker will likely fold functions declared as inline. Template functions and template classes are implicitly inline, so for example, all uses of std::vector<std::string> will (likely) be implicitly folded together.
(Or are you assuming that a debug flag is used so that all inlined functions are not really inlined by the compiler?)
> Good question but I don't know the answer.
Don’t know if that’s the final answer here (didn’t actually investigate), but system is the time spent in syscalls, and locks are usually provided by the OS, aka syscalls (though there might be userland components to avoid the syscall e.g. futex).
Thus the need for synchronisation of threaded program generally leads to higher system time. Though here mold is clearly a lot more efficient as well (lower user time).
https://github.com/rui314/mold#why-does-the-speed-of-linking...
It has an introduction section on what is a linker and why you need one. The gist is, linker is the piece of software that puts together different source file, be it at compile time or runtime. So, the faster is your linker the quicker the app compiles and opens.
The Solaris Linkers and Libraries docs are very good and mostly relevant to Linux, with fewer distractions about Windows: