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

[Rui Ueyama via llvm-dev]

On Wed, Nov 16, 2016 at 12:55 PM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 16 November 2016 at 20:44, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I'm thinking to enable --threads by default. We now have real users, and
> > they'll be happy about the performance boost.
>
> Will it detect single-core computers and disable it? What is the
> minimum number of threads that can run in that mode?
>
> Is the penalty on dual core computers less than the gains? If you
> could have a VM with only two cores, where the OS is running on one
> and LLD threads are running on both, it'd be good to measure the
> downgrade.
>

As a quick test, I ran the benchmark again with "taskset -c 0" to use only
one core. LLD still spawns 40 threads because my machine has 40 cores (20
physical cores), so 40 threads ran on one core.

With --no-threads (one thread on a single core), it took 6.66 seconds to
self-link. With -thread (40 threads on a single core), it took 6.70
seconds. I guess they are mostly in error margin. So I think it wouldn't
hurt single core machine.

Rafael may be running his benchmarks and will bring his results.

Rafael's concern is also very real. I/O and memory consumption are
> important factors on small footprint systems, though I'd be happy to
> have a different default per architecture or even carry the burden of
> forcing a --no-threads option every run if the benefits are
> substantial.
>
> If those issues are not a concern, than I'm in favour!
>
>
> >  - 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.
>
> Agreed.
>
>
> >  - 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.
>
> Strongly agreed.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161116/d9173f75/attachment.html>