Re: Large parallel glibc builds.

[Florian Weimer <fweimer at redhat dot com>]

On 12/24/2015 04:13 PM, Carlos O'Donell wrote:
> On 12/23/2015 11:00 AM, Florian Weimer wrote:
>>> What do you think is the bottleneck here?
>>
>> On top of the scaling issue of some of the threading tests, it looks as
>> if lack of parallelism between subdirectories is the major culprit.
>> This means that single-thread performance determines build and test
>> times to a large extent.
> 
> Interesting. Is it avoidable though?

The kernel does much better.  Here's an âmake -j240â allmodconfig build,
to show what *is* possible:

real    2m1.820s
user    137m12.582s
sys     42m41.267s

This requires careful attention to detail, and avoiding make features
which are quite slow (implicit rules, recursion, maybe vpaths as well).
 Obviously, it's still not economical to run kernel builds on such large
machines, but this scalability work also benefits more affordable
2-socket machines.

Peter Miller's essay about the challenges of recursive make comes to my
mind. :)

> Would the next step be to time subdirectories and see which ones
> are the slowest?

I don't know.  I think the first step would be to contemplate what we
want from the build system, and what we need for tests.

>> math/gen-libm-test.pl is major seralization point during builds (not
>> tests).  During tests, it's compilation test-tgmath2.c (related to poor
>> performance of debugging information generation in GCC, as discussed
>> before).
> 
> That step is relatively fast, even if were to serialize all operations,
> it can't entirely explain the abysmal performance above?

test-tgmath2.c takes multiple minutes to compile on Fedora 23 with the
system GCC, I think.

Florian