<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 10:00 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Thu, Nov 17, 2016 at 9:50 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</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"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Nov 17, 2016, at 9:41 AM, Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-3525003452663147710m_4007311398697330363Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 17, 2016 at 6:12 AM, Teresa Johnson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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"><span class="gmail-m_-3525003452663147710m_4007311398697330363m_3256324661011689167gmail-m_-5809187657192067599gmail-">> Sounds like threading isn't beneficial much beyond the second CPU...<br>
> Maybe blindly creating one thread per core isn't the best plan...<br>
<br>
</span>parallel.h is pretty simplistic at the moment. Currently it creates<br>
one per SMT. One per core and being lazy about it would probably be a<br>
good thing, but threading is already beneficial and improving<br>
parallel.h an welcome improvement.<br></blockquote><div><br></div></span><div>Instead of using std::thread::hardware_concurre<wbr>ncy (which is one per SMT), you may be interested in using the facility I added for setting default ThinLTO backend parallelism so that one per physical core is created, llvm::heavyweight_hardware_con<wbr>currency() (see D25585  and r284390). The name is meant to indicate that this is the concurrency that should be used for heavier weight tasks (that may use a lot of memory e.g.).</div></div></div></div></blockquote><div><br></div><div>Sorry for my ignorance, but what's the point of running the same number of threads as the number of physical cores instead of HT virtual cores? If we can get better throughput by not running more than one thread per a physical core, it feels like HT is a useless technology.</div></div></div></div></div></blockquote><div><br></div></span><div>It depends on the use-case: with ThinLTO we scale linearly with the number of physical cores. When you get over the number of physical cores you still get some improvements, but that’s no longer linear.</div><div>The profitability question is a tradeoff one: for example if each of your task is very memory intensive, you may not want to overcommit the cores or increase the ratio of available mem per physical core.</div><div><br></div><div>To take some number as an example: if your average user has a 8GB machine with 4 cores (8 virtual cores with HT), and you know that each of your parallel tasks is consuming 1.5GB of memory on average, then having 4 parallel workers threads to process your tasks will lead to a peak memory of 6GB, having 8 parallel threads will lead to a peak mem of 12GB and the machine will start to swap.</div><div><br></div><div>Another consideration is that having the linker issuing threads behind the back of the build system isn’t great: the build system is supposed to exploit the parallelism. Now if it spawn 10 linker jobs in parallel, how many threads are competing for the hardware?</div><div><br></div><div>So, HT is not useless, but it is not universally applicable or universally efficient in the same way.</div><div><br></div><div>Hope it makes sense!</div></div></div></blockquote><div><br></div></span><div>Thank you for the explanation! That makes sense.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>Ok, sure - I was just suggesting based on Rafael's comment above about lld currently creating one thread per SMT and possibly wanting one per core instead. It will definitely depend on the characteristics of your parallel tasks (which is why the name of the interface was changed to include "heavyweight" aka large memory intensive, since the implementation may return something other than # physical cores for other architectures - right now it is just implemented for x86 otherwise returns thread::hardware_concurrency()).</div><div><br></div><div>Teresa</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span style="font-family:times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>