<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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16 November 2016 at 20:44, Rui Ueyama via llvm-dev<br>
<span class="gmail-"><<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></blockquote><div><br></div><div>As a quick test, I ran the benchmark again with "taskset -c 0" to use only one core. LLD still spawns 40 threads because my machine has 40 cores (20 physical cores), so 40 threads ran on one core.</div><div><br></div><div>With --no-threads (one thread on a single core), it took 6.66 seconds to self-link. With -thread (40 threads on a single core), it took 6.70 seconds. I guess they are mostly in error margin. So I think it wouldn't hurt single core machine.</div><div><br></div><div>Rafael may be running his benchmarks and will bring his results.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
<br>
If those issues are not a concern, than I'm in favour!<br>
<span class="gmail-"><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="gmail-"><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>