<div dir="ltr">Sure. If you want to add --thread-count (but not other options, such as --thread-count-initial), that's fine with me.<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 8:09 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_5756265595568316918HOEnZb"><div class="m_5756265595568316918h5">On Thu, Nov 17, 2016 at 8:04 PM, Davide Italiano <<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>> wrote:<br>
> On Thu, Nov 17, 2016 at 7:34 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
>> On Thu, Nov 17, 2016 at 6:30 PM, Davide Italiano <<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>> wrote:<br>
>>><br>
>>> On Thu, Nov 17, 2016 at 1:20 PM, Rafael Espíndola via llvm-dev<br>
>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> >><br>
>>> >> Thank you for the explanation! That makes sense.<br>
>>> >><br>
>>> >> Unlike ThinLTO, each thread in LLD consumes very small amount of memory<br>
>>> >> (probably just a few megabytes), so that's not a problem for me. At the<br>
>>> >> final stage of linking, we spawn threads to copy section contents and<br>
>>> >> apply<br>
>>> >> relocations, and I guess that causes a lot of memory traffic because<br>
>>> >> that's<br>
>>> >> basically memcpy'ing input files to an output file, so the memory<br>
>>> >> bandwidth<br>
>>> >> could be a limiting factor there. But I do not see a reason to limit<br>
>>> >> the<br>
>>> >> number of threads to the number of physical core. For LLD, it seems<br>
>>> >> like we<br>
>>> >> can just spawn as many threads as HT provides.<br>
>>> ><br>
>>> ><br>
>>> > It is quite common for SMT to *not* be profitable. I did notice some<br>
>>> > small wins by not using it. On an intel machine you can do a quick<br>
>>> > check by running with half the threads since they always have 2x SMT.<br>
>>> ><br>
>>><br>
>>> I had the same experience. Ideally I would like to have a way to<br>
>>> override the number of threads used by the linker.<br>
>>> gold has a plethora of options for doing that, i.e.<br>
>>><br>
>>> --thread-count COUNT Number of threads to use<br>
>>> --thread-count-initial COUNT<br>
>>> Number of threads to use in initial pass<br>
>>> --thread-count-middle COUNT Number of threads to use in middle pass<br>
>>> --thread-count-final COUNT Number of threads to use in final pass<br>
>>><br>
>>> I don't think we need the full generality/flexibility of<br>
>>> initial/middle/final, but --thread-count could be useful (at least for<br>
>>> experimenting). The current interface of `parallel_for_each` doesn't<br>
>>> allow to specify the number of threads to be run, so, assuming lld<br>
>>> goes that route (it may not), that should be extended accordingly.<br>
>><br>
>><br>
>> I agree that these options would be useful for testing, but I'm reluctant to<br>
>> expose them as user options because I wish LLD would just work out of the<br>
>> box without turning lots of knobs.<br>
>><br>
><br>
> I share your view that lld should work fine out-the-box. I think an alternative<br>
> is having the option as hidden, maybe. I consider the set of users<br>
> tinkering with linker options not large, although there are some<br>
> people who like to override/"tune" the linker anyway, so IMHO we<br>
> should expose a sane default and let users decide if they care or not<br>
> (a similar example is what we do for --thinlto-threads or<br>
> --lto-partitions, even if in the last case we still have that set to 1<br>
> because it's not entirely clear what's a reasonable number).<br>
><br>
<br>
</div></div>I've seen a case where the linker was pinned to a specific subset of the CPUs<br>
and many linker invocations were launched in parallel.<br>
(actually, this is the only time when I've seen --threads for gold used).<br>
I personally don't expect this to be the common use-case, but it's not hard<br>
to imagine complex build systems adopting a similar strategy.<br>
<div class="m_5756265595568316918HOEnZb"><div class="m_5756265595568316918h5"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</div></div></blockquote></div><br></div></div>