Thread: Optimization levels when compiling PostgreSQL...
In an attempt to beef up the PostgreSQL port for FreeBSD, I've added an option for adding additional optimization, similar to what MySQL does by compiling the server with -O6. I'm only compiling at -O3 with the flag at the moment, however I wanted to ping the idea around to make sure this isn't some land-mine that doesn't show up in the regression tests. My database hardware is in transition to a new data center so I can't test this on my own at the moment. :-/ The size difference between -O and -O3 is only 200K or so... does anyone think that it'd be safe to head to -O6 on a wide scale? I don't want to cream the FreeBSD user base with a bogus recommendation. I figure this is a database and 200KB doesn't amount to bo-diddly compared to my data sizes so this seems acceptable in that dept. I'm even thinking about going so far as to have flex required for the build dependencies and setting -Cf or -CF for building the scanner (need to check the archives for which turned out to be faster). I'm also tinkering with the idea of automatically turn off fsync if optimize is set. Objections? -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> The size difference between -O and -O3 is only 200K or so... does
> anyone think that it'd be safe to head to -O6 on a wide scale?
Dunno. I'm not aware of any bits of the code that are unportable enough
to break with max optimization of any correct compiler. But you might
find such a bug. Or a bug in your compiler. Are you feeling lucky
today?
My feeling is that gcc -O2 is quite well tested with the PG code.
I don't have any equivalent confidence in -O6. Give it a shot for
beta-testing, for sure, but I'm iffy about calling that a
production-grade database release...
> I'm even thinking about going so far as to have flex required for the
> build dependencies and setting -Cf or -CF for building the scanner
> (need to check the archives for which turned out to be faster).
Um, didn't we do that stuff already in the standard build? AFAIK
you cannot build PG with any lexer except flex, and Peter already
hacked the flags.
> I'm also tinkering with the idea of automatically turn off fsync if
> optimize is set.
No-bloody-way. Trusting your compiler is an entirely separate issue
from whether you trust your disk hardware, power source, etc. Puh-leez
do not muddy the waters by introducing a port-specific variation in
choices that only the DBA of a particular installation should make.
regards, tom lane
> > The size difference between -O and -O3 is only 200K or so... does > > anyone think that it'd be safe to head to -O6 on a wide scale? > > Dunno. I'm not aware of any bits of the code that are unportable > enough to break with max optimization of any correct compiler. But > you might find such a bug. Or a bug in your compiler. Are you > feeling lucky today? > > My feeling is that gcc -O2 is quite well tested with the PG code. I > don't have any equivalent confidence in -O6. Give it a shot for > beta-testing, for sure, but I'm iffy about calling that a > production-grade database release... I'm thinking about changing this from a beta port to a -devel port that I'll periodically update with snapshots. I'll turn on -O6 for the -devel port and -O2 for production for now. If I don't hear of any random bogons in the code I'll see if I can't increase it further to -O3 and beyond at a slow/incremental rate. Has there been any talk of doing incremental -snapshots of the code base? I've really fallen inlove with the concept for development. Having incremental changes is much easier to cope with than massive steps forward. > > I'm even thinking about going so far as to have flex required for the > > build dependencies and setting -Cf or -CF for building the scanner > > (need to check the archives for which turned out to be faster). > > Um, didn't we do that stuff already in the standard build? AFAIK > you cannot build PG with any lexer except flex, and Peter already > hacked the flags. Hrm, I should go check the archives, but I thought what was used was one step below -C[fF] and was used because of size concerns for embedded databases. My memory for what happens on mailing lists seems to be fading though so I'll look it up. > > I'm also tinkering with the idea of automatically turn off fsync if > > optimize is set. > > No-bloody-way. Trusting your compiler is an entirely separate issue > from whether you trust your disk hardware, power source, etc. > Puh-leez do not muddy the waters by introducing a port-specific > variation in choices that only the DBA of a particular installation > should make. Whoop, guess I won't do that. :~) Thanks. -sc -- Sean Chittenden
Tom Lane wrote: > Sean Chittenden <sean@chittenden.org> writes: > > The size difference between -O and -O3 is only 200K or so... does > > anyone think that it'd be safe to head to -O6 on a wide scale? > > Dunno. I'm not aware of any bits of the code that are unportable enough > to break with max optimization of any correct compiler. But you might > find such a bug. Or a bug in your compiler. Are you feeling lucky > today? > > My feeling is that gcc -O2 is quite well tested with the PG code. > I don't have any equivalent confidence in -O6. Give it a shot for > beta-testing, for sure, but I'm iffy about calling that a > production-grade database release... And of course the big question is whether you will see any performance improvement with -O6 vs. -O2. My guess is no. > > > I'm even thinking about going so far as to have flex required for the > > build dependencies and setting -Cf or -CF for building the scanner > > (need to check the archives for which turned out to be faster). > > Um, didn't we do that stuff already in the standard build? AFAIK > you cannot build PG with any lexer except flex, and Peter already > hacked the flags. Yes, I thought that was a done deal too. > > I'm also tinkering with the idea of automatically turn off fsync if > > optimize is set. > > No-bloody-way. Trusting your compiler is an entirely separate issue > from whether you trust your disk hardware, power source, etc. Puh-leez > do not muddy the waters by introducing a port-specific variation in > choices that only the DBA of a particular installation should make. Tom is right. Hardware/power reliability is a different issue. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 9 Sep 2002, Sean Chittenden wrote: > I'm thinking about changing this from a beta port to a -devel port > that I'll periodically update with snapshots. I'll turn on -O6 for > the -devel port and -O2 for production for now. If I don't hear of > any random bogons in the code I'll see if I can't increase it further > to -O3 and beyond at a slow/incremental rate. Keep in mind that, while gcc is pretty stable for i386, the higher optimization levels (above -O2) do tend to have bogons on other processors, that vary with which version of gcc you're running. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
Sean Chittenden wrote: > Hrm, I should go check the archives, but I thought what was used was > one step below -C[fF] and was used because of size concerns for > embedded databases. My memory for what happens on mailing lists seems > to be fading though so I'll look it up. I see in parser/Makefile: FLEXFLAGS = -CF andifdef FLEX $(FLEX) $(FLEXFLAGS) -o'$@' $<else @$(missing) flex $< $@endif -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Curt Sampson wrote: > On Mon, 9 Sep 2002, Sean Chittenden wrote: > > > I'm thinking about changing this from a beta port to a -devel port > > that I'll periodically update with snapshots. I'll turn on -O6 for > > the -devel port and -O2 for production for now. If I don't hear of > > any random bogons in the code I'll see if I can't increase it further > > to -O3 and beyond at a slow/incremental rate. > > Keep in mind that, while gcc is pretty stable for i386, the higher > optimization levels (above -O2) do tend to have bogons on other > processors, that vary with which version of gcc you're running. Yes, last I heard, FreeBSD/alpha doesn't work in PostgreSQL if compiled with -O2. You can see template/freebsd for that alpha flag override. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > > The size difference between -O and -O3 is only 200K or so... does > > > anyone think that it'd be safe to head to -O6 on a wide scale? > > > > Dunno. I'm not aware of any bits of the code that are unportable enough > > to break with max optimization of any correct compiler. But you might > > find such a bug. Or a bug in your compiler. Are you feeling lucky > > today? > > > > My feeling is that gcc -O2 is quite well tested with the PG code. > > I don't have any equivalent confidence in -O6. Give it a shot for > > beta-testing, for sure, but I'm iffy about calling that a > > production-grade database release... > > And of course the big question is whether you will see any performance > improvement with -O6 vs. -O2. My guess is no. Agreed, however some of the loop-unrolling might prove to have some optimization, but we'll see. I'd like to think that there's some actual value in -O6 beyond the geek appeal of being able to say it's been compiled with all the optimizations possible. ::shrug:: > > I'm thinking about changing this from a beta port to a -devel port > > that I'll periodically update with snapshots. I'll turn on -O6 for > > the -devel port and -O2 for production for now. If I don't hear of > > any random bogons in the code I'll see if I can't increase it further > > to -O3 and beyond at a slow/incremental rate. > > Keep in mind that, while gcc is pretty stable for i386, the higher > optimization levels (above -O2) do tend to have bogons on other > processors, that vary with which version of gcc you're running. Fully aware of these!!! I've got a few systems running GCC 3.2 and 3.3 and it's touch and go above -O3, but most of these bogons are mozilla and GUI related when it comes to complex thread handling. For more simple single threaded procs, the bugs get found out about pretty quickly and end up making their way back into the GCC src tree. I'm thinking -O6 for the -devel port should work nicely as a way of testing things out. -sc -- Sean Chittenden
Sean Chittenden wrote: > > > > The size difference between -O and -O3 is only 200K or so... does > > > > anyone think that it'd be safe to head to -O6 on a wide scale? > > > > > > Dunno. I'm not aware of any bits of the code that are unportable enough > > > to break with max optimization of any correct compiler. But you might > > > find such a bug. Or a bug in your compiler. Are you feeling lucky > > > today? > > > > > > My feeling is that gcc -O2 is quite well tested with the PG code. > > > I don't have any equivalent confidence in -O6. Give it a shot for > > > beta-testing, for sure, but I'm iffy about calling that a > > > production-grade database release... > > > > And of course the big question is whether you will see any performance > > improvement with -O6 vs. -O2. My guess is no. > > Agreed, however some of the loop-unrolling might prove to have some > optimization, but we'll see. I'd like to think that there's some > actual value in -O6 beyond the geek appeal of being able to say it's > been compiled with all the optimizations possible. ::shrug:: And you think the answer is ... I think we all know what the answer is. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > > > My feeling is that gcc -O2 is quite well tested with the PG > > > > code. I don't have any equivalent confidence in -O6. Give it > > > > a shot for beta-testing, for sure, but I'm iffy about calling > > > > that a production-grade database release... > > > > > > And of course the big question is whether you will see any > > > performance improvement with -O6 vs. -O2. My guess is no. > > > > Agreed, however some of the loop-unrolling might prove to have > > some optimization, but we'll see. I'd like to think that there's > > some actual value in -O6 beyond the geek appeal of being able to > > say it's been compiled with all the optimizations possible. > > ::shrug:: > > And you think the answer is ... I think we all know what the answer > is. :-) I think the newbie/l33t geek appeal of being able to say something's compiled and works with -O6 is probably worth more in terms of marketing than it is interms of actual technical merrit. Those that need 10K lookups per second should be serializing data into a bdb file with a unique key and not using a relational database (or helping out with pgsql-replication). :~) -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes: > Agreed, however some of the loop-unrolling might prove to have some > optimization, but we'll see. I'd like to think that there's some > actual value in -O6 beyond the geek appeal of being able to say it's > been compiled with all the optimizations possible. ::shrug:: BTW, -O3 is the highest GCC optimization level; anything higher than that is synonymous with -O3, I believe. Also, -O3 doesn't have anything to do with loop unrolling, AFAIK. As for the value of enabling that flag, it depends IMHO on the performance gain you see. If there is a significance difference, let -hackers know, and it might be worth considering enabling it by default for certain platforms. If the performance difference is negligible (which is what I'd suspect), I don't think it's worth the code bloat, reduced debuggability, or the potential for running into more compiler bugs. Also, if -O3 *is* a good compiler option, I dislike the idea of enabling it for your own packages but no one else's. IMHO distributors should not futz with packages more than is strictely necessary, and a change like this seems both unwarranted, and potentially dangerous. If -O3 is a good idea, we should make the change for the appropriate platforms in the official source, and let it get the widespread testing it requires. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Sean Chittenden <sean@chittenden.org> writes: > Has there been any talk of doing incremental -snapshots of the code > base? I don't really see the point. Snapshots of development code are available from CVS anyway -- and if you're going to be running a pre-alpha version of a relational database, I don't think that knowledge of CVS is an onerous requirement. At any rate, the problem with releasing snapshots is that the system catalogs would change so often that upgrading between snapshots would be a headache. i.e. the changes required to upgrade from a 2 week old development snapshot to a current snapshot would still be non-trivial, significantly reducing the usefulness of snapshots, IMHO. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> -----Original Message----- > From: Neil Conway [mailto:neilc@samurai.com] > Sent: 10 September 2002 05:58 > To: Sean Chittenden > Cc: Tom Lane; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Optimization levels when compiling > PostgreSQL... > > > Sean Chittenden <sean@chittenden.org> writes: > > Has there been any talk of doing incremental -snapshots of the code > > base? > > I don't really see the point. Snapshots of development code > are available from CVS anyway -- and if you're going to be > running a pre-alpha version of a relational database, I don't > think that knowledge of CVS is an onerous requirement. > > At any rate, the problem with releasing snapshots is that the > system catalogs would change so often that upgrading between > snapshots would be a headache. i.e. the changes required to > upgrade from a 2 week old development snapshot to a current > snapshot would still be non-trivial, significantly reducing > the usefulness of snapshots, IMHO. Snapshots can be found here: ftp://ftp.postgresql.org/pub/dev/ Regards, Dave.
Neil Conway <neilc@samurai.com> writes:
> Sean Chittenden <sean@chittenden.org> writes:
>> Has there been any talk of doing incremental -snapshots of the code
>> base?
> I don't really see the point. Snapshots of development code are
> available from CVS anyway -- and if you're going to be running a
> pre-alpha version of a relational database, I don't think that
> knowledge of CVS is an onerous requirement.
There's also the nightly automatic snapshot tarball on the FTP server,
if you don't want to learn CVS...
regards, tom lane
> > Agreed, however some of the loop-unrolling might prove to have some > > optimization, but we'll see. I'd like to think that there's some > > actual value in -O6 beyond the geek appeal of being able to say it's > > been compiled with all the optimizations possible. ::shrug:: > > BTW, -O3 is the highest GCC optimization level; anything higher than > that is synonymous with -O3, I believe. Also, -O3 doesn't have > anything to do with loop unrolling, AFAIK. In terms of instruction optimization, yes. Above that is where it does the loop unrolling, inlining, and other various tweaks. > As for the value of enabling that flag, it depends IMHO on the > performance gain you see. If there is a significance difference, let > -hackers know, and it might be worth considering enabling it by > default for certain platforms. If the performance difference is > negligible (which is what I'd suspect), I don't think it's worth the > code bloat, reduced debuggability, or the potential for running into > more compiler bugs. Agreed. Later today I'll thump on my good SCSI system and let you know what happens. > Also, if -O3 *is* a good compiler option, I dislike the idea of > enabling it for your own packages but no one else's. IMHO > distributors should not futz with packages more than is strictely > necessary, and a change like this seems both unwarranted, and > potentially dangerous. If -O3 is a good idea, we should make the > change for the appropriate platforms in the official source, and let > it get the widespread testing it requires. Agreed, but the testing's got to start someplace. :~) The -O3 is a tunable that you can optionally set or unset so it's not like I'm forcing it to be on (thought it will by default for the -devel port). -sc -- Sean Chittenden
> > Has there been any talk of doing incremental -snapshots of the > > code base? > > I don't really see the point. Snapshots of development code are > available from CVS anyway -- and if you're going to be running a > pre-alpha version of a relational database, I don't think that > knowledge of CVS is an onerous requirement. Agreed, however it's nice to have landmarks along the way, such as a point of stability or once a new feature gets rolled in and need some use (ex: schemas or auto-commit). > At any rate, the problem with releasing snapshots is that the system > catalogs would change so often that upgrading between snapshots > would be a headache. i.e. the changes required to upgrade from a 2 > week old development snapshot to a current snapshot would still be > non-trivial, significantly reducing the usefulness of snapshots, > IMHO. Don't doubt it at all, but that reminds me: I need to add a message reminding the developer to re-initdb when installing this version. This is for a -devel port that'd track the new features that are being rolled into postgresql so there's a large degree of competence assumed when someone installs this particular version from the tree. I've also slapped up some big warnings to make sure that it's developers only. At the moment, however, I think I'll probably roll my own tarballs when an island of stability has been found unless the snapshot server is holding onto its snaps for several months at a time. -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> Don't doubt it at all, but that reminds me: I need to add a message
> reminding the developer to re-initdb when installing this version.
The catversion check isn't good enough for you?
It seems you are busily reinventing a bunch of decisions that have
already been made, and in most cases have stood the test of time.
Perhaps you should be less eager to make this Sean's Own Postgres
Version, and more eager to be pushing out something that matches
what everyone else is testing.
regards, tom lane
> > Don't doubt it at all, but that reminds me: I need to add a message
> > reminding the developer to re-initdb when installing this version.
>
> The catversion check isn't good enough for you?
Nope, it's good enough and then some. I've gotten in the habit of
just re-initdb'ing and figured that's what the rest of the world did:
didn't realize there was a way of testing the catalog versions. My
life seems to be spent inside the DB and not playing with it from the
CLI.
> It seems you are busily reinventing a bunch of decisions that have
> already been made, and in most cases have stood the test of time.
> Perhaps you should be less eager to make this Sean's Own Postgres
> Version, and more eager to be pushing out something that matches
> what everyone else is testing.
Ouch! I hope not. Testing gcc optimizations and adding a developers
port of PostgreSQL hopefully isn't for just myself.
PostgreSQL has a chunk of work that needs to happen when setting it up
or upgrading and I am trying to smooth out as much of that as possible
such that installing PostgreSQL gets to the point of having it
reasonably tuned for the OS its being installed on after installing
the port. Its not that install PostgreSQL is hard, far from, but
there's a reasonable checklist of things that needs to happen and that
requires a certain requisite knowledge of the database, tuning, and
the OS you're on: something, for better or worse, I assume most
users/DBA's don't have. In a typical install, I generally do some
variation of the following:
*) setenv CFLAGS '-g -O3'
*) make
*) pg_dumpall > ~/db_dump
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh stop
*) make deinstall
*) make install
*) mv $PGDATA $PGDATA.old
*) initdb
*) diff -c $PGDATA.old/data/postgresql.conf $PGDATA/data/postgresql.conf > $PGDATA/data/postgresql.conf.patch
*) cd $PGSQL/data; patch -p0 < postgresql.conf.patch
*) edit postgresql.conf
*) ${LOCALBASE}/etc/rc.d/010.pgsql.sh start
*) psql -f ~/db_dump
*) vacuumdb -a -f -z
*) tweak various sysctl's to increase fd's, etc.
*) hopefully don't have to recompile the kernel with more shmem, etc
On some hosts, I've even got a script that I run that does all of that
for me because it's the exact same procedure every time. :-/ Getting
as much of that done and taken care of as possible would probably be
appreciated and enjoyed by others. It's not fool-proof, don't get me
wrong, but there's certainly some of that that can be automated, and
with tunables I'd like to for usabilities sake.
::shrug:: Usability's a touchy subject though and none of this will be
on by default so as to not offend the power-users out there. -sc
--
Sean Chittenden
Sean Chittenden writes:
> Hrm, I should go check the archives, but I thought what was used was
> one step below -C[fF] and was used because of size concerns for
> embedded databases. My memory for what happens on mailing lists seems
> to be fading though so I'll look it up.
The particular decision was -CF vs. -CFa ("a" for alignment). The latter
was about 2% faster in the test case but increased the size of the
executable by 80 kB.
Note that the test case was extremely contrived -- parsing of about 70 MB
of uninteresting commands with little to no other activity. For a normal
command the scanner overhead is really small.
On the other hand, the test case was run on a x86 machine which is not
known for being sensitive to alignment. So on a different architecture
you might get more significant speedups. Try it if you like.
--
Peter Eisentraut peter_e@gmx.net
Neil Conway writes: > Also, if -O3 *is* a good compiler option, I dislike the idea of > enabling it for your own packages but no one else's. IMHO distributors > should not futz with packages more than is strictely necessary, and a > change like this seems both unwarranted, and potentially dangerous. If > -O3 is a good idea, we should make the change for the appropriate > platforms in the official source, and let it get the widespread > testing it requires. I disagree. Choosing the compiler options is exactly the job of the installer, packager, or distributor. That's why you can specify CFLAGS on the command line after all, and most distributors' build environments make use of that. I don't think we're doing anyone a service if we spread wild speculations about how risky certain compiler options are. If your compiler creates broken code, don't use it. Packagers are expected to know about their compiler. If they create broken packages and behave irresponsibly about it they won't be making packages much longer. -- Peter Eisentraut peter_e@gmx.net
On Wed, 11 Sep 2002, Peter Eisentraut wrote: > I disagree. Choosing the compiler options is exactly the job of the > installer, packager, or distributor. If there is one, yes. > I don't think we're doing anyone a service if we spread wild speculations > about how risky certain compiler options are. If your compiler creates > broken code, don't use it. Packagers are expected to know about their > compiler. If they create broken packages and behave irresponsibly about > it they won't be making packages much longer. However, many users are not as knowledgable as packagers, but may still be compiling from source. For those people, I don't think it's unreasonable to say, "Use -O2 unless you know what you are doing." (I'm not sure we're actually disagreeing here, but I just wanted to make this point clear.) cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
On Tuesday 10 September 2002 09:31 pm, Curt Sampson wrote: > On Wed, 11 Sep 2002, Peter Eisentraut wrote: > > I disagree. Choosing the compiler options is exactly the job of the > > installer, packager, or distributor. > If there is one, yes. If the enduser is directly compiling the source, then that user is responsible for passing the flags desired -- they become their own packager. > However, many users are not as knowledgable as packagers, but may > still be compiling from source. For those people, I don't think it's > unreasonable to say, "Use -O2 unless you know what you are doing." I still remember when the Alpha port _required_ -O0. And it was documented that way, IIRC. Compiling from source implies certain knowledge. Automated from source builds, such as ports or linux distributions such as Gentoo can handle this in their own build systems. If someone can figure out how to override the default, then they can deal with the results, IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tue, 10 Sep 2002, Lamar Owen wrote: > I still remember when the Alpha port _required_ -O0. And it was documented > that way, IIRC. Good. It would also be very nice if, in situations like this, the configure script could detect this and use -O0 when compiling on the alpha. > Compiling from source implies certain knowledge. No it doesn't. All it means is that someone's using a system for which they don't have a package handy. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
Sean Chittenden <sean@chittenden.org> writes: > I'm thinking about changing this from a beta port to a -devel port > that I'll periodically update with snapshots. I'll turn on -O6 for > the -devel port and -O2 for production for now. If I don't hear of > any random bogons in the code I'll see if I can't increase it further > to -O3 and beyond at a slow/incremental rate. -O3 is usually slower than -O2 because of increased code size due to automatic inlining. With GCC, -O4 etc. are all equivalent to -O3. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898