LLD supports multi-threading, and it seems to be working well as you can see in a recent result. In short, LLD runs 30% faster with --threads option and more than 50% faster if you are using --build-id (your mileage may vary depending on your computer). However, I don’t think most users even don’t know about that because --threads is not a default option.
I’m thinking to enable --threads by default. We now have real users, and they’ll be happy about the performance boost.
I can’t think of problems with that, but I want to write a few notes about that:
We still need to focus on single-thread performance rather than multi-threaded one because it is hard to make a slow program faster just by using more threads.
We shouldn’t do “too clever” things with threads. Currently, we are using multi-threads only at two places where they are highly parallelizable by nature (namely, copying and applying relocations for each input section, and computing build-id hash). We are using parallel_for_each, and that is very simple and easy to understand. I believe this was a right design choice, and I don’t think we want to have something like workqueues/tasks in GNU gold, for example.
Run benchmarks with --no-threads if you are not focusing on multi-thread performance.