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

Rui Ueyama via llvm-dev
Wed, 16 Nov 2016 21:29:57 -0000

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.
>
> 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.
>

On such a computer, you don't want to enable threads at all, no? If so, you
can build LLVM without LLVM_ENABLE_THREADS.


> 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/1d2ad80c/attachment.html>