[llvm-dev] LLD: time to enable --threads by default

[Rafael Espíndola via llvm-dev]

I will do a quick benchmark run.

Other than the observations you have my only concern is the situation
where many lld invocations run in parallel, like in a llvm build where
there many outputs in bin/. Our task system doesn't know about load,
so I worry that it might degrade performance in that case.

Cheers,
Rafael


On 16 November 2016 at 15:44, Rui Ueyama <ruiu at google.com> wrote:
> 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.
>
> Any concerns?
>
> 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.
>