[Scons-dev] SCons-like build system

Tue Jan 27 04:48:49 EST 2015

Wow. Fortunately when we were still using make I had the opprutunity to replace our recursive build with a non recursive one. Some of the way that was set up has propagated to our new build but basically, every executable has a recipe which contains all the libraries the executable needs to link and each library contains its own recipe so hopefully that can be leveraged.

From: jason.l.kenny at intel.com At: Jan 23 2015 15:03:32
To: Tom Tanner (BLOOMBERG/ LONDON), scons-dev at scons.org
Subject: RE: [Scons-dev] SCons-like build system

I understand this problem. This is one main thing Parts tries to address. It uses information about the different component to figure out what not to load.  This requires the build to be laid out in some sort of component based like build, vs a recursive make, which may not be a big deal, depending on how your project is laid out. The result for example of a massive build I have here is a “do nothing” build takes  ~7-20 second vs the normal ~15-20 minutes it would normally take. Incremental build also are reduced to minutes ( depending on what changed of course)

I honestly believe this can be better yet.. but we requires more work.  The main issue with spawn issue that we pushed, was found when a build for this large  product moved from rhel4 to rhel5. The time increased from 2 hours to 4+. It was the spawning issue. Something changed that really made this worse. Once we had this fixed rhel5 build went to 2 hours and the old rhel4 based build went to ~1.5 hours. 

Jason

From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Tom Tanner (BLOOMBERG/ LONDON)
Sent: Thursday, January 22, 2015 2:49 AM
To: scons-dev at scons.org
Subject: Re: [Scons-dev] SCons-like build system

Having been poking around in this, I see that 'posix_spawn' cleans to be availble on both aix and solaris (at least they have man pages). Which is a relief for me. However, my current grief is that  a 'do nothing' build is still taking 20 minutes to traverse the tree. *part* of this is because I check the md5sum on each file to make sure someone hasn't gone and edit/patched/hacked a generated target (which happens more often than is desirable), but that  isn't the bulk of the time taken.

I suspect I could leverage the fact that we use git to get the sha1 of certain repositories that are known not to be changed by us and if we find a file therein, to use  the combined sha1 of the repos might improve that at the cost of potentially spurious rebuilds if one of the repos changed but the others didn't as i wouldn't be reading all the files.

From: scons-dev at scons.org At: Jan 21 2015 14:47:48

To: dl9obn at darc.de, scons-dev at scons.org
Subject: Re: [Scons-dev] SCons-like build system

Yes posix_spawn will make a big difference on posix based systems. More so as 
the build get larger and the build system needs more memory. Windows default 
spawn logic is more like posix_spawn so it does not suffer in this case.

The core issue is that a build system spawns lots of processes to do work ( 
compiler, linkers, etc..). the common spawn logic in posix system is to fork, 
which requires the system to setup a copy on write  of the build system memory 
to "child" process. As it turns out this is awful for a build system as the 
child process never touches the "shared" memory from the process, however the 
parent process is busy touching it as it setting states, etc. This requires 
system to copy all the memory we are writing to in the build system.  Given 
that the build system will in general being spawning lot of process. This leads 
to a worse cases memory access pattern on any modern chip architecture, more so 
as the build gets larger and the build system needs more memory. Given the 
posix spawn avoids the cloning the memory, the memory access pattern goes to a 
much better case ( ie  no copy of memory to new page tables, which lead to 
lower tlb misses and then being more likely we are in cache)

Jason

-----Original Message-----
From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Constantine
Sent: Wednesday, January 21, 2015 6:19 AM
To: dl9obn at darc.de; SCons developer list
Subject: Re: [Scons-dev] SCons-like build system

Hello Dirk,

I tested this SCons version with memory optimizations on 10000 C++ files.
Updated graphs can be found here: 
https://github.com/aqualid/aqualid/wiki/Benchmark-results-for-v0.5

I see about 20% improvement.

As I understand using posix_spawn function should improve performance on Linux 
and OSX.

Best regards,
Constantine.

On 01/13/15 21:55, Dirk Bächle wrote:
> As a follow-up of these investigations I have prepared a patch that 
> switches SCons (especially the Node class) to using slots, in order to 
> reduce the overall memory consumption. If you're interested in trying 
> it out with your benchmark, you can get a copy with
>
>   hg clone http://bitbucket.org/dirkbaechle/scons_experimental -r 
> switch_node_to_slots
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150127/5a534729/attachment.html>