<div dir="ltr"><div>LLD supports multi-threading, and it seems to be working well as you can see in a recent <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=287140" target="_blank">result</a>. 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.</div><div><br></div><div>I'm thinking to enable --threads by default. We now have real users, and they'll be happy about the performance boost.</div><div><br></div><div>Any concerns?</div><div><br></div><div>I can't think of problems with that, but I want to write a few notes about that:</div><div><br></div><div> - 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.</div><div><br></div><div> - 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.</div><div><br></div><div> - Run benchmarks with --no-threads if you are not focusing on multi-thread performance.</div><div><br></div></div>