llvm dev - Nov 2011 - [LLVMdev] RFC: Upcoming Build System Changes

Am 01.11.2011 18:04, schrieb Joerg Sonnenberger:
> On Tue, Nov 01, 2011 at 11:09:41AM +0100, Joachim Durchholz wrote:
>> On the reasons why make-based builds are slow, Peter Miller has some
>> insight to offer:
>> http://miller.emu.id.au/pmiller/books/rmch/ .
>> I'm not sure how widely recognized that paper is. Maybe it's
widely
>> known and today's build times stem from other things than recursive
make.
>
> Please stop pointing to that article. It should be called "GNU make
> considered harmful" if anything, since most of the content is a direct
> result of issues in that tool.
The salient point in that article is about common use of recursive make 
not doing what most people expect. In particular, if the dependencies 
are a DAG instead of a tree, you need to put everything into one big 
makefile since recursive make's design cannot handle the situation 
correctly.
This is a property of the basic design of make, and cannot be fixed 
unless by changing what a recursive make actually does.
(I have built my own make, in Rexx, as I was young and needed the tool. 
This otherwise unremarkable endeavour forced me to learn more about 
make's semantic than a mere student should be exposed to.)

 > As I said earlier in this thread:

Sorry, I missed that post.

 > LLVM is
> nowhere big enough in terms of subdirectories that recursive make is a
> significant contributor to build time.
Did you verify that this is the case? Some of the gotchas in the make 
semantics can cause exponential behaviour, and that's easy to overlook 
if the N in your O(2^N) behaviour is incremented only occasionally.

Regards,
Jo

Dear All,

We have a new 32 core machine, so I ran some numbers.  These results are 
for compiling all of LLVM and Clang in a Debug build from scratch.  The 
first number is the -j argument to make, and the rest is the result of 
the bash builtin time command.

2:  1612.950u 161.293s 15:04.92 196.0%       0+0k 0+0io 0pf+0w

4:  1624.101u 164.121s  8:00.74 371.9%       0+0k 0+0io 0pf+0w

8:  1657.272u 176.211s  4:35.31 665.9%       0+0k 0+0io 0pf+0w

16: 1681.512u 189.706s  2:48.96 1107.4%      0+0k 0+0io 0pf+0w

32: 1698.817u 209.073s  2:02.88 1552.6%      0+0k 0+0io 0pf+0w


The processors are Intel(R) Xeon(R) CPU E7- 8837  @ 2.67GHz.

Note that I had two other processes running, so 2 cores were unavailable 
throughout the -j32 build.

I did not use CMake but the standard autoconf + Makefile build.

Not sure if this helps, but here it is, for what it's worth.

-- John T.

Hello John.

John Criswell <criswell at illinois.edu> writes:

[snip]
> I did not use CMake but the standard autoconf + Makefile build.
>
> Not sure if this helps, but here it is, for what it's worth.
Very interesting, thanks!

CMake introduces more parallelism and it would be great to see how much
impact it makes. If you can, please run the cmake build with -j32, just
to compare with the `make' build.

If you simply ran `configure && time make' for the autoconf build,
that
builds the Debug+Asserts mode. For replicating it on cmake, run

mkdir build-directory && cd build-directory
cmake -DCMAKE_BUILD_TYPE=Debug path/to/llvm/source/root
time make -j32

Thanks again.