headers
Elliot Murphy | 1 Feb 2003 03:58

RE: Jam2.5 and precompiled headers

My experiences with a large project that takes from 1-2 hours to build
(using build.exe from the Windows DDK on a 2-proc system) is that using
batch compilation gave an average of 10-15% speedup. Like Chris says - the
larger your project the more important these incremental performance
improvements become.
-elliot

|-----Original Message-----
|From: Chris Antos [mailto:chrisant <at> windows.microsoft.com] 
|Sent: Friday, January 31, 2003 6:35 PM
|To: Matt Armstrong
|Cc: Jacob Gorm Hansen; jam mailling list
|Subject: RE: [jamming] Jam2.5 and precompiled headers
|
|
|I said you get maximum win from batch compilation WHEN YOU USE
|PRECOMPILED HEADERS.  :-)  (caps to add visibility to key point)
|
|Between batch compilation and precompiled headers, the latter gives a
|bigger win.  Combining the two gains some additional 
|improvements (or at
|least it did in the big project I worked on a few years ago -- 
|right now
|I'm working on a very small project only a couple thousand files, and I
|haven't checked to make sure the compiler still has those additional
|improvements, but it's hard to imagine they'd have been removed :-).
|
|But 65 versus 60 seconds -- based on your timings, that's nearly a 10%
|boost even without precompiled headers.  If your build took 1:48:00
|(~1.8 hours) then you could expect about 10 minutes improvement (~1.65
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Armstrong | 1 Feb 2003 17:56

Re: Jam2.5 and precompiled headers

"Chris Antos" <chrisant <at> windows.microsoft.com> writes:

> I said you get maximum win from batch compilation WHEN YOU USE
> PRECOMPILED HEADERS.  :-)  (caps to add visibility to key point)

Interestingly, I see performance gains of 70-80% when a whole library
is turned into a single .c file (e.g. add one .c file that #includes
all the others and compile that).

Unfortunately this doesn't always work, given the semantics of a C
compilation unit.

> Between batch compilation and precompiled headers, the latter gives
> a bigger win.  Combining the two gains some additional improvements

I've also looked into trying to get visual c++ to support parallel
builds (-j 2).  Unfortunately, the compiler barfs because it wants to
build a .pdb file.  :-(
Permalink | Reply | 3 comments |
headers
Elliot Murphy | 1 Feb 2003 18:37

RE: Jam2.5 and precompiled headers

Without knowing exactly what error you're getting from visual c++,
we had trouble on parallel builds with vc++ until we added the /Fd
switch, which allows you to specify which name should be used
for the pdb file. (I haven't done this with jam yet or I would post
more details).
-elliot

|-----Original Message-----
|From: Matt Armstrong [mailto:matt <at> lickey.com] 
|Sent: Saturday, February 01, 2003 11:56 AM
|To: Chris Antos
|Cc: Jacob Gorm Hansen; jam mailling list
|Subject: Re: [jamming] Jam2.5 and precompiled headers
|
|
|"Chris Antos" <chrisant <at> windows.microsoft.com> writes:
|
|> I said you get maximum win from batch compilation WHEN YOU USE
|> PRECOMPILED HEADERS.  :-)  (caps to add visibility to key point)
|
|Interestingly, I see performance gains of 70-80% when a whole library
|is turned into a single .c file (e.g. add one .c file that #includes
|all the others and compile that).
|
|Unfortunately this doesn't always work, given the semantics of a C
|compilation unit.
|
|
|> Between batch compilation and precompiled headers, the latter gives
|> a bigger win.  Combining the two gains some additional improvements
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Antos | 1 Feb 2003 21:02
Picon
Favicon

RE: Jam2.5 and precompiled headers

I got roughly 50% performance gain simply from using precompiled
headers; i.e. I cut my build time basically in half.  You can
potentially get less or more improvement depending on what your
precompiled header actually includes; i.e. how much redundant processing
is offloaded into the pch.  Take an additional 10% for batch
compilation, and that's in the neighborhood of the gain you're seeing
from turning the whole library into a single .c file.  You're right,
it's not always possible.  Some other drawbacks are that it can make
several things very difficult and you may get very poor linker
optimization results, and may have a lot of dead code left in the
executable, bogus DLL dependencies, and etc.

By the way, to solve the multiple compiler processes blocking each other
from accessing the pdb file, use the /Z7 compiler flag instead of /Zi.

-----Original Message-----
From: Matt Armstrong [mailto:matt <at> lickey.com] 
Sent: Saturday, February 01, 2003 8:56 AM
To: Chris Antos
Cc: Jacob Gorm Hansen; jam mailling list

"Chris Antos" <chrisant <at> windows.microsoft.com> writes:

> I said you get maximum win from batch compilation WHEN YOU USE
> PRECOMPILED HEADERS.  :-)  (caps to add visibility to key point)

Interestingly, I see performance gains of 70-80% when a whole library
is turned into a single .c file (e.g. add one .c file that #includes
all the others and compile that).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell | 3 Feb 2003 15:38
Picon

Confused by SubDir

Hi all,

When i put: SubDir TOP d1 ... dn ;
into a jamfile, is the directory: TOP d1 ... dn
always supposed to be the current directory of that jamfile,
or is it designed so that the following commands can be made to
work in a directory other than the current one?

http://public.perforce.com/public/jam/src/Jambase

rule SubDir
{
	#
	# SubDir TOP d1 ... ;
	#
	# Support for a project tree spanning multiple directories.
	#
	# SubDir introduces a Jamfile that is part of a project tree whose
	# root is $(TOP).  TOP is a user-selected variable name for the
	# tree; d1 ... are the directory elements that lead from the root
	# of the tree to the directory of the Jamfile.
	#
	# When jam reads the Jamfile in the current working directory
	# (CWD), the first SubDir call sets $(TOP) to the back path to
	# the project root for use by subsequent SubDir calls.  The path
	# contains one ../ for each directory from the root.
	#
	# Each SubDir call sets the (fixed) variable $(SUBDIR) to the path
	# from the CWD to the named directory.  SubDir also sets other
	# Jambase variables (SEARCH_SOURCE, LOCATE_TARGET) to $(SUBDIR),
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Armstrong | 3 Feb 2003 18:08

Re: Confused by SubDir

Russell <rjshaw <at> iprimus.com.au> writes:

> When i put: SubDir TOP d1 ... dn ;
>
> into a jamfile, is the directory: TOP d1 ... dn
> always supposed to be the current directory of that jamfile,
> or is it designed so that the following commands can be made to
> work in a directory other than the current one?

The first -- the directory components "d1 ... dn" are supposed to name
the directory that the Jamfile is in, relative to the top of the
source tree.
Permalink | Reply | 0 comments |
headers
Craig McPheeters | 3 Feb 2003 19:36
Picon

Re: Jam2.5 and precompiled headers

> Subject: Re: [jamming] Jam2.5 and precompiled headers
> From: Matt Armstrong <matt <at> lickey.com>
> Date: Sat, 01 Feb 2003 09:56:07 -0700
> 
> "Chris Antos" <chrisant <at> windows.microsoft.com> writes:
> 
...
> > Between batch compilation and precompiled headers, the latter gives
> > a bigger win.  Combining the two gains some additional improvements
> 
> I've also looked into trying to get visual c++ to support parallel
> builds (-j 2).  Unfortunately, the compiler barfs because it wants to
> build a .pdb file.  :-(

I needed to solve this problem for a build I was working on at the time.
We are using pre-compiled headers and .pdb debugging - I don't think its
possible to use that combination with the standard version of jam.

There is /Z7 and /Zi debugging available.  /Z7 placed the debug info into
the .obj file, /Zi places the debug info into an external file which you can
name.

With pre-compiled headers, you'll compile a single file with a switch to
generate a pre-compiled header file (.pch) and then provide that file on some
set of files (all the files for a library, all the files for a .dll, etc.)

Using multiple jobs with .pch files is easy, just set it up.  Using multiple
jobs with .pdb debugging is possible, if you specify a different database
for every .obj file.  But this makes the build area quite a lot larger than
normal.  If two compile actions are running at the same time with the same .pdb
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell | 5 Feb 2003 11:58
Picon

Jamming with subdirectories

Hi all,

In the top level Jamfile, i've got:

SubDir TOP ;
Main myprog : main.c analog.c serial.c
SubInclude TOP main ;
SubInclude TOP analog ;
SubInclude TOP serial ;

In the 'main' subdirectory jamfile, i have:

SubDir TOP main ;
Objects main.c ;

In the 'analog' subdirectory jamfile, i have:

SubDir TOP analog ;
Objects analog.c ;

In the 'serial' subdirectory jamfile, i have:

SubDir TOP serial ;
Objects serial.c ;

When i run jam from the top directory, i get errors:
   don't know how to make main.c
   don't know how to make analog.c
   don't know how to make serial.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ingo Weinhold | 5 Feb 2003 13:47
Picon

Re: Jamming with subdirectories

On Wed, 5 Feb 2003, Russell wrote:

> In the top level Jamfile, i've got:
>
> SubDir TOP ;
> Main myprog : main.c analog.c serial.c
> SubInclude TOP main ;
> SubInclude TOP analog ;
> SubInclude TOP serial ;
>
> In the 'main' subdirectory jamfile, i have:
>
> SubDir TOP main ;
> Objects main.c ;
>
> In the 'analog' subdirectory jamfile, i have:
>
> SubDir TOP analog ;
> Objects analog.c ;
>
> In the 'serial' subdirectory jamfile, i have:
>
> SubDir TOP serial ;
> Objects serial.c ;
>
>
> When i run jam from the top directory, i get errors:
>    don't know how to make main.c
>    don't know how to make analog.c
>    don't know how to make serial.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matze Braun | 6 Feb 2003 16:23
Picon
Gravatar

Problems with SubDir rule in jam-2.5rc1

Hi,

I just tried updating to jam-2.5 and I'm having problems with the SubDir 
rule now. It is impossible to set a custom TOP path now. With jam 2.4 I 
did something like this:

Directory Layout:
source/Jamfile
source/Jamrules
source/...several subdirs with Jamfiles...

build/Jamfile

Jamfile in source looks like this:
SubDir TOP ;

SubInclude ... ;
... ;

The build/Jamfile looked like this:

TOP = ../source ;
include $(TOP)/Jamfile ;

so I was able to build source into another directory easily. However in 
the jam-2.5 rules, my Jamrules file isn't included when I'm setting the 
TOP variable :-/

Greetings,
	Matze
(Continue reading)

Permalink | Reply | 0 comments |

Gmane