Обсуждение: Compile timing
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
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
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) #
> 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
> 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
> 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) #
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
> > 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
> > 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