<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="-1">Very
good. I just saw that Alex is making some good points.<br>
</font></p>
<font size="-1">
</font>
<p><font size="-1">The TBB pages earlier are an excellent reference
for
multi-threading or for TBB multi-tasking. They illustrate issues
that
a good threading design should consider that are not commonly
recognized when embarking on a that design. I would say the task
scheduler is their most comprehensive approach.</font></p>
<font size="-1">
</font>
<p><font size="-1">Clearly, I am not familiar enough with LLVM to be
making any
definite prescription and recommend your more knowledgeable
judgment.</font></p>
<font size="-1">
</font>
<p><font size="-1">But in the spirit of attempting a more complete
perspective we may
consider that a threading design for LLVM is not simple. And I
suspect not nearly as simple, not saying that the current ideas
are
simple in that I do not understand them, as has been explored to
this point.</font></p>
<font size="-1">
</font>
<p><font size="-1">For example, you remarked there are use cases,
and having a
realistic appreciation for what use cases there may be is
important,
where a multi-threading compile would be useful. But then on
that
point, if we were to have threading on the compile to an object
file,
would we then overload the cores, make them slower, when using
ninja to compile LLVM?
How would the compile threading take into account this other use
case, if that was something to consider?</font></p>
<font size="-1">
</font>
<p><font size="-1">Do we encumber the LLVM design with threading
such that the
trade-off for that design against its use-case benefits is not
well
justified? My sense is that if threading was judged a reasonable
goal
that a preliminary design would be presented after some research
that
would initially complement non-threading goals, a general
improvement
that would yield a better track for threading later. This
reflects
the sense that a good threading design is not simple and will
impact
a significant portion of LLVM. And it could well be that that is
what is happening now.<br>
</font></p>
<font size="-1">
</font>
<p><font size="-1">How would threading impact future LLVM
development? My sense is
that in some reasonable portion of future development would be
made
more difficult.</font></p>
<font size="-1">
</font>
<p><font size="-1">You mentioned that single object compiling would
have a benefit. Here are
some factors that could mitigate that benefit.</font></p>
<p><font size="-1">Although core speeds
are not expected to increase and remain in the 4-5 gigahertz
rate,
IPC (instructions per cycle) is expected to increase at a slow
rate.
Over time there will be a natural reduction in compile time for
some
benchmark compile.</font></p>
<p><font size="-1">There is also a gain in compile time for small
source files as against larger source files and some argument
with
regard to design could be made for some maximum source file size
to
reduce complexity that would also address keeping compile time
down.
Is there a reason to expect an increase in source file size that
would increase compile time?</font></p>
<p><font size="-1">Noting the LLVM compile test from my
prior post gave an average compile time of 14*0.1532 = 2.1448
seconds, is compile time a significant or marginal issue? What
would
be the target for an average compile time?</font></p>
<font size="-1">
</font>
<p><font size="-1">Neil Nelson</font></p>
<div class="moz-cite-prefix"><font size="-1">On 3/2/20 11:07 AM,
Chris Lattner wrote:<br>
</font></div>
<blockquote type="cite"
cite="mid:D29169A7-A09C-4C27-9EF3-B657963A6EFD@nondot.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<font size="-1">On Mar 1, 2020, at 1:29 AM, Neil Nelson via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>> wrote:</font><br
class="">
<div>
<blockquote type="cite" class=""><span style="font-size: small;"
class="">The point</span><br class="">
<div class="">
<div class=""><font class="" size="-1"> <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="">
</blockquote>
</body>
</html>