[CMake] Obtaining improved GNU make performance on Makefiles generated by cmake

[Alan W. Irwin]

Hi Bill:

I just now tested (with the build on one of the PLplot C examples)
the assertion that specific targets will have less latency
with the new approach.  Here are the results.

software at raven>  make x10c
[  0%] Built target plhershey-unicode-gen
[  0%] Built target plhershey-unicode.h_built
[  0%] Built target csirocsa
[ 16%] Built target csironn
[100%] Built target plplotd
[100%] Built target x10c

As you can see from this, the number of dependencies is fairly small.
Furthermore, the VERBOSE=1 results indicate there are no actual commands
being run by the above so this is a measure of true latency.

Here are the corresponding latency results:

2.4.8:
software at raven> time make x10c >& /dev/null

real    0m0.217s
user    0m0.160s
sys     0m0.068s

2.7-20080324:
software at raven> time make x10c >& /dev/null

real    0m0.209s
user    0m0.168s
sys     0m0.036s

Repeat runs indicate for this special case with a small number of
dependencies, the timing errors are typically +/- 0.002 s.  The conclusion
therefore is the cvs version wins on latency for a specific target by a
marginal amount that is just above the timing noise.

On 2008-03-24 15:28-0400 Bill Hoffman wrote:

> OK, so for a small project like PLplot, where it does a make in 1 to 2 
> seconds if nothing needs to be done, this stuff really does does not matter 
> that much.
> As for the new way cmake 
> does the depend stuff, I think the new approach is much better for larger 
> projects like KDE/ParaView.

Large projects have the most serious potential latency problems (could be
minutes rather than seconds if the number of dependencies is very high) so I
agree they should be the ones driving latency improvements rather than
PLplot. The only advantage of using PLplot for such tests is the initial
build can be done in less than a minute so doing differential comparisons
between various CMake versions is easy to do.

In any case, it's fundamentally important not to guess about latency because
reducing latency is generally a hard problem. Thus, before the next release
I hope somebody steps forward with actual latency numbers for specific
targets and the "all" target for large projects like KDE/ParaView.  But it
currently doesn't look good since the indications from the PLplot tests
(which so far is the only hard data that has been reported) is the latency
for "make all" will be substantially worse while the latency for specific
targets with a lot fewer dependencies then "all" are only marginally better
for the cvs version compared to 2.4.8.

The principal conclusion I want to emphasize is the PLplot latency results
are just an indication of what to expect in general, and what we need is
hard latency numbers for big projects like KDE, ParaView, etc., (where
latency issues should be more severe than in the PLplot case).  That's the
only way we can move forward with any further attempts to substantially
improve latency.

I have previously asked Alex to do the KDE case.  Bill, would you be willing
to measure latency for ParaView for cmake 2.4.8 and the present cvs version
of CMake?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________