Thread: Compile timing

Compile timing

From
Bruce Momjian
Date:
Someone mentioned that it took them quite a while to compile the
PostgreSQL code.  My wallclock time is 3:52 for a compile with -O1 using
gcc 2.7.2.1.  This is on a dual-PII 350MHz running BSD/OS 4.01.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Compile timing

From
Lamar Owen
Date:
Bruce Momjian wrote:
> 
> Someone mentioned that it took them quite a while to compile the
> PostgreSQL code.  My wallclock time is 3:52 for a compile with -O1 using
> gcc 2.7.2.1.  This is on a dual-PII 350MHz running BSD/OS 4.01.

Someone is me.  Someone only has a Pentium 133 with 256K L2 cache and
32MB RAM.  Someone is also running KDE/X on this laptop.  

Using egcs 1.1.2 under Linux 2.2.5.(RedHat 6.0).

You have a machine that is 5 times faster than mine.  Also, this is more
than a compile -- this is a whole sequence of events -- cleaning out the
old build directory, unpacking the tarball, applying patches,
configure;make;make install, some other sequences of events, and then
cpio'ing and compressing to build several rpm's.  So, about two thirds
of the time is actually spent compiling, which is still a little slow
compared to your result.

If my machine compiled PostgreSQL as fast as yours, I'd be one happy
camper!

Lamar Owen
WGCR Internet Radio


Re: [HACKERS] Compile timing

From
wieck@debis.com (Jan Wieck)
Date:
Lamar Owen wrote:

>
> Bruce Momjian wrote:
> >
> > Someone mentioned that it took them quite a while to compile the
> > PostgreSQL code.  My wallclock time is 3:52 for a compile with -O1 using
> > gcc 2.7.2.1.  This is on a dual-PII 350MHz running BSD/OS 4.01.

Hmmm,

    Is  there  something  wrong with your system, Bruce?  My 64MB
    333MHz singe-PII (same gcc version under Linux 2.2.10) does a
    -O1 clean-compile in 3:28.

    Maybe  the SMP overhead is eating up the missing cycles.  You
    would like a parallelized make to outperform me again - no?

> You have a machine that is 5 times faster than mine.  Also, this is more
> than a compile -- this is a whole sequence of events -- cleaning out the
> old build directory, unpacking the tarball, applying patches,
> configure;make;make install, some other sequences of events, and then
> cpio'ing and compressing to build several rpm's.  So, about two thirds
> of the time is actually spent compiling, which is still a little slow
> compared to your result.

    Lamar, shouldn't you run at least the  regression  suite  too
    before building the rpm's?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

Re: [HACKERS] Compile timing

From
Bruce Momjian
Date:
> Lamar Owen wrote:
> 
> >
> > Bruce Momjian wrote:
> > >
> > > Someone mentioned that it took them quite a while to compile the
> > > PostgreSQL code.  My wallclock time is 3:52 for a compile with -O1 using
> > > gcc 2.7.2.1.  This is on a dual-PII 350MHz running BSD/OS 4.01.
> 
> Hmmm,
> 
>     Is  there  something  wrong with your system, Bruce?  My 64MB
>     333MHz singe-PII (same gcc version under Linux 2.2.10) does a
>     -O1 clean-compile in 3:28.
> 
>     Maybe  the SMP overhead is eating up the missing cycles.  You
>     would like a parallelized make to outperform me again - no?

I knew someone would find this an interesting topic.

I should also mention I have 256MB of RAM, and Baracuda SCSI-Ultra
drives with tagged queuing enabled.

OK, I turned off my custom flags, and got for -O1:
real    3m8.080suser    2m21.752ssys     0m35.291s

I usually do:
CUSTOM_COPT=-g -Wall -O1 -Wmissing-prototypes -Wmissing-declarations

My bet is the symbol output takes some time to produce.  I noticed the
link of the postgres binary was faster without -g.

With parallelization, using gmake -j2, I got:
real    3m8.980suser    2m23.442ssys     0m36.142s

Not sure why -j2 is not faster than normal -j, unless gmake knows to use
-j2 on a 2-cpu system by default.  Looking at the xps output, I don't
see multiple compiles being performed by gmake.

Gmake -j fails because compiles happen before supporting files are
created.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Compile timing

From
Thomas Lockhart
Date:
> Not sure why -j2 is not faster than normal -j...

I was just looking at this a little while ago at work. It is not
faster because gmake does not propagate the "-j2" flag to submakes, on
the (correct) theory that you might get a geometrically growing system
load, rather than just keeping two makes running through all the
subdirectories.

This is the behavior of "-j", unless you specify it without a numeric
parameter, in which case it *does* allow parallel submakes.

The first time I tried "-j", I did it without reading the man pages
and without specifying a numeric parameter. It did a magnificent job
of bringing down my system trying to build ACE/TAO, a *large* Corba
package. Chewed up all of real memory, then all of swap; not sure if I
ran out of process slots or memory first but it wasn't pretty. It was
*very* fast though :)
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [HACKERS] Compile timing

From
wieck@debis.com (Jan Wieck)
Date:
> With parallelization, using gmake -j2, I got:
>
>    real    3m8.980s
>    user    2m23.442s
>    sys     0m36.142s
>
> Not sure why -j2 is not faster than normal -j, unless gmake knows to use
> -j2 on a 2-cpu system by default.  Looking at the xps output, I don't
> see multiple compiles being performed by gmake.

    Because it hasn't prallelized :-)

    The  -j2  wasn't  handed  down  to  the submakes and I'm sure
    there's only one started from the top.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

Re: [HACKERS] Compile timing

From
Lamar Owen
Date:
Jan Wieck wrote:
>     Lamar, shouldn't you run at least the  regression  suite  too
>     before building the rpm's?

Well, once the compile passes regression on a particular architecture,
IMO it doesn't need to be done for every compile of that version of
PostgreSQL.

However, as part of the testing for the built RPM's, I do run the
regression tests (which I have packaged into the RPM set --
postgresql-test) before releasing.  The regression tests don't take too
long (unless I run bigtest).

Running regression as part of the RPM build is a possibility, however.

As it stands, Intel fails two tests (float8 and geometry) and Alpha
fails two tests (geometry and another one that I can't remember right
now) -- one of which is due to the documented problem with sort order on
the Alpha (Uncle George has thoroughly covered that topic, recently).

The RPM building development cycle is a little different than most. 
RPM's are built in a fully automatic fashion -- a single command
invocation (rpm -ba postgresql.spec) compiles, mungs, and packages all
the way to the binary RPM's, then it cleans up.  Getting to that point,
however, can be a challenge, as some patches are necessary to get a
build in the FHS-compliant RedHat environment.  It took me about 2 hours
to get a good build of 6.5.2, due to the need for a couple of Makefile
patches in the perl client (in particular, the src/interfaces Makefile
issues a 'perl5 makefile.pl' command, when there is no executable on
RedHat 6 named perl5), along with some other munging that had to be
done.

I have to think in the mindset of a packager, not a developer, when
doing this -- but I have to also keep up with development in order to
package.  And I LOVE it!

So, in short, every binary RPM set I build for RedHat 6 has been
installed on my personal laptop running a close to virgin RedHat 6
installation -- and has had regression run.  The set built for RedHat
5.2 has had the same thing done on my inhouse utility machine, which is
a puny little machine (486/100 with 16MB).  It takes almost two hours to
build the binary RPM set on that machine.  But, then again, that is also
my amanda server and is quite loaded.

Lamar Owen
WGCR Internet Radio


Re: [HACKERS] Compile timing

From
Bruce Momjian
Date:
> > Not sure why -j2 is not faster than normal -j...
> 
> I was just looking at this a little while ago at work. It is not
> faster because gmake does not propagate the "-j2" flag to submakes, on
> the (correct) theory that you might get a geometrically growing system
> load, rather than just keeping two makes running through all the
> subdirectories.
> 
> This is the behavior of "-j", unless you specify it without a numeric
> parameter, in which case it *does* allow parallel submakes.
> 
> The first time I tried "-j", I did it without reading the man pages
> and without specifying a numeric parameter. It did a magnificent job
> of bringing down my system trying to build ACE/TAO, a *large* Corba
> package. Chewed up all of real memory, then all of swap; not sure if I
> ran out of process slots or memory first but it wasn't pretty. It was
> *very* fast though :)
> 

Yes, make -j without a number does so many makes here the compile fails
too, and the load average soars.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Compile timing

From
Bruce Momjian
Date:
> > Not sure why -j2 is not faster than normal -j...
> 
> I was just looking at this a little while ago at work. It is not
> faster because gmake does not propagate the "-j2" flag to submakes, on
> the (correct) theory that you might get a geometrically growing system
> load, rather than just keeping two makes running through all the
> subdirectories.
> 
> This is the behavior of "-j", unless you specify it without a numeric
> parameter, in which case it *does* allow parallel submakes.
> 
> The first time I tried "-j", I did it without reading the man pages
> and without specifying a numeric parameter. It did a magnificent job
> of bringing down my system trying to build ACE/TAO, a *large* Corba
> package. Chewed up all of real memory, then all of swap; not sure if I
> ran out of process slots or memory first but it wasn't pretty. It was
> *very* fast though :)

I just tried:
gmake MAKE="gmake -j 2"

and that fails because we can't parellize because we need certain
includes.  I can't seem to get the proper includes to happen before it
fails.

I am getting:

gmake[3]: Entering directory
`/var/local/src/pgsql/CURRENT/pgsql/src/backend/access/common'
gmake[3]: *** No rule to make target `hash/SUBSYS.o'.  Stop.
gmake[3]: Leaving directory `/var/local/src/pgsql/CURRENT/pgsql/src/backend/acce

Seems it is trying to complete the linking before the compiles are done.
If I made -j2 happen only in directories with compiles, and not outside,
that might fix it.  The propogation of -j2 to subdirectories and the
exponential explosion is exactly what happens.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026