<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 16, 2016 at 12:55 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16 November 2016 at 20:44, Rui Ueyama via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I'm thinking to enable --threads by default. We now have real users, and<br>
> they'll be happy about the performance boost.<br>
<br>
</span>Will it detect single-core computers and disable it? What is the<br>
minimum number of threads that can run in that mode?<br>
<br>
Is the penalty on dual core computers less than the gains? If you<br>
could have a VM with only two cores, where the OS is running on one<br>
and LLD threads are running on both, it'd be good to measure the<br>
downgrade.<br>
<br>
Rafael's concern is also very real. I/O and memory consumption are<br>
important factors on small footprint systems, though I'd be happy to<br>
have a different default per architecture or even carry the burden of<br>
forcing a --no-threads option every run if the benefits are<br>
substantial.<br></blockquote><div><br></div><div>On such a computer, you don't want to enable threads at all, no? If so, you can build LLVM without LLVM_ENABLE_THREADS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If those issues are not a concern, than I'm in favour!<br>
<span class=""><br>
<br>
>  - We still need to focus on single-thread performance rather than<br>
> multi-threaded one because it is hard to make a slow program faster just by<br>
> using more threads.<br>
<br>
</span>Agreed.<br>
<span class=""><br>
<br>
>  - We shouldn't do "too clever" things with threads. Currently, we are using<br>
> multi-threads only at two places where they are highly parallelizable by<br>
> nature (namely, copying and applying relocations for each input section, and<br>
> computing build-id hash). We are using parallel_for_each, and that is very<br>
> simple and easy to understand. I believe this was a right design choice, and<br>
> I don't think we want to have something like workqueues/tasks in GNU gold,<br>
> for example.<br>
<br>
</span>Strongly agreed.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>