<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Mar 1, 2020, at 1:29 AM, Neil Nelson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><span style="font-size: small;" class="">The point</span><br class=""><div class=""><div class=""><font size="-1" class="">
<br class="">
When the number of compiles exceeds the number of cores such that
all the cores are utilized, nothing is gained by trying to
multi-thread the individual compiles. In fact, loading up the
cores with more threads or tasks than there are cores will reduce
compiling efficiency because of time slicing. And sequencing
through more tasks than less when the cores are not overloaded
will reduce compiling efficiency because more tasks have to be
loaded and unloaded to the cores.</font></div></div></blockquote><br class=""></div><div>That makes a lot of sense Neil. Two counterpoints though:</div><div><br class=""></div><div>1) In development situations, it is common to rebuild one file (the one you changed) without rebuilding everything. Speeding that up is useful.</div><div><br class=""></div><div>2) LLVM is a library that is used for a lot more than just C compilers. Many of its use cases are not modeled by bulk “compile all the code” workloads like you describe.</div><div><br class=""></div><div><br class=""></div><div>You’re right that multithreading isn’t a panacea, but in my opinion, it is important to be able to provide access to multicore compilation for use cases that do benefit from it.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>