[llvm-dev] Multi-Threading Compilers

[Neil Nelson via llvm-dev]

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 
comprehensive approach.

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?

Neil Nelson

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 
>> cores.
>
> 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 
> useful.
>
> 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.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200302/59ac70ba/attachment.html>