[llvm-dev] Multi-Threading Compilers
Neil Nelson via llvm-dev
llvm-dev at lists.llvm.org
Mon Mar 2 13:06:06 PST 2020
Very good. I just saw that Alex is making some good points.
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
Clearly, I am not familiar enough with LLVM to be making any definite
prescription and recommend your more knowledgeable judgment.
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.
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?
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.
How would threading impact future LLVM development? My sense is that in
some reasonable portion of future development would be made more difficult.
You mentioned that single object compiling would have a benefit. Here
are some factors that could mitigate that benefit.
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.
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?
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?
On 3/2/20 11:07 AM, Chris Lattner wrote:
> On Mar 1, 2020, at 1:29 AM, Neil Nelson via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> The point
>> 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
> That makes a lot of sense Neil. Two counterpoints though:
> 1) In development situations, it is common to rebuild one file (the
> one you changed) without rebuilding everything. Speeding that up is
> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev