Make performance (was Re: Question about KQUEUE code in make(1))
Max Okumoto wrote:
> David Rhodus <sdrhodus@gmail.com> writes:
>
>>On Thu, 18 Nov 2004 13:50:44 -0800, Max Okumoto <okumoto@ucsd.edu> wrote:
>>
>>>I am near the KQUEUE patches for make(1), and I was wondering if
>>>we want this code.
>>>
>>> Max
>>
>>Did anyone in fbsd ever get the kqueue stuff working properly with make(1) ?
>>
>>--
>> -David
>> Steven David Rhodus
>> <drhodus@machdep.com>
>
>
> It looks like the code is turned off in the Makefile.
>
> # There is no obvious performance improvement currently.
> # CFLAGS+=-DUSE_KQUEUE
>
> It does compile on leaf, so I am inclined to leave it in since
> it reduces the diffs :-)
>
> Max
It's not entirely on topic WRT KQUEUE, but since we're talking about
make's performance:
To be complete, it would appear that make -j X doesn't increase
performance by any significant value. Indeed, when I mounted /usr/obj
async, there was no performance gain, so it's pretty clear that disk I/O
isn't the issue here. When running make on a single blade of DFCluster,
it finishes in 1:36:30.12. When distributed across 5 blades with distcc,
using 20 make processes, it finishes in 1:01:30.08, a performance gain
of only (roughly) 33% -- only a 6.6% gain per machine. I suppose that
this is a substantial gain, but I had expected something more
distributing the load across 5 of the blades. Obviously, a lot of the
wait comes from the multiple builds of iberty and binutils.
Compared to the 21-minutes it took me to build the world on Leaf
yesterday, and the optimizations we made on DFCluster, I'm pretty
unimpressed with make's performance when distributed.
I hope to go back to the datacenter later this week and reset the other
two blades to test the performance with two extra systems, but I doubt
that it will make much a difference.
I understand that Jeroen is busy working on getting (at least some of)
the build process ported over to jam, which, to my understanding, should
handle distribution much better. (Whether this becomes the official
method used remains to be seen, but if it can improve handling of
distribution and dependancies (I also understand this to mean that
binutils won't have to be rebuilt 6 or 8 times during the process), it'd
at least be useful for an alternative build platform (especially for
those of us with clusters :)).
Oh, I've just spoken to Jeroen, and it appears that jam was an ``idea
for later''. Looks like later just became now :).
--Devon