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

[Davide Italiano via llvm-dev]

On Thu, Nov 17, 2016 at 1:20 PM, Rafael Espíndola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>
>> Thank you for the explanation! That makes sense.
>>
>> Unlike ThinLTO, each thread in LLD consumes very small amount of memory
>> (probably just a few megabytes), so that's not a problem for me. At the
>> final stage of linking, we spawn threads to copy section contents and apply
>> relocations, and I guess that causes a lot of memory traffic because that's
>> basically memcpy'ing input files to an output file, so the memory bandwidth
>> could be a limiting factor there. But I do not see a reason to limit the
>> number of threads to the number of physical core. For LLD, it seems like we
>> can just spawn as many threads as HT provides.
>
>
> It is quite common for SMT to *not* be profitable. I did notice some
> small wins by not using it. On an intel machine you can do a quick
> check by running with half the threads since they always have 2x SMT.
>

I had the same experience. Ideally I would like to have a way to
override the number of threads used by the linker.
gold has a plethora of options for doing that, i.e.

  --thread-count COUNT        Number of threads to use
  --thread-count-initial COUNT
                              Number of threads to use in initial pass
  --thread-count-middle COUNT Number of threads to use in middle pass
  --thread-count-final COUNT  Number of threads to use in final pass

I don't think we need the full generality/flexibility of
initial/middle/final, but --thread-count could be useful (at least for
experimenting). The current interface of `parallel_for_each` doesn't
allow to specify the number of threads to be run, so, assuming lld
goes that route (it may not), that should be extended accordingly.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare