<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 17, 2016 at 6:30 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"><span class="">On Thu, Nov 17, 2016 at 1:20 PM, Rafael Espíndola via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">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 apply<br>
>> relocations, and I guess that causes a lot of memory traffic because that's<br>
>> basically memcpy'ing input files to an output file, so the memory bandwidth<br>
>> could be a limiting factor there. But I do not see a reason to limit the<br>
>> number of threads to the number of physical core. For LLD, it seems 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>
</span>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></blockquote><div><br></div><div>I agree that these options would be useful for testing, but I'm reluctant to expose them as user options because I wish LLD would just work out of the box without turning lots of knobs.<br></div><div><br></div></div></div></div>