Horton

Thread

  1. Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-09T21:27:20Z

    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

  2. Re: Optimization levels when compiling PostgreSQL...

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-09-10T02:40:48Z

    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

  3. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T02:54:19Z

    > > 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

  4. Re: Optimization levels when compiling PostgreSQL...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-09-10T02:55:36Z

    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, Pennsylvania 19073

  5. Re: Optimization levels when compiling PostgreSQL...

    Curt Sampson <cjs@cynic.net> — 2002-09-10T02:56:22Z

    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 all light.  --XTC

  6. Re: Optimization levels when compiling PostgreSQL...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-09-10T02:57:01Z

    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

and
	
	ifdef 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, Pennsylvania 19073

  7. Re: Optimization levels when compiling PostgreSQL...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-09-10T02:59:18Z

    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, Pennsylvania 19073

  8. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T03:02:19Z

    > > > 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

  9. Re: Optimization levels when compiling PostgreSQL...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-09-10T03:04:58Z

    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, Pennsylvania 19073

  10. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T03:18:38Z

    > > > > 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

  11. Re: Optimization levels when compiling PostgreSQL...

    Neil Conway <neilc@samurai.com> — 2002-09-10T04:51:12Z

    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

  12. Re: Optimization levels when compiling PostgreSQL...

    Neil Conway <neilc@samurai.com> — 2002-09-10T04:57:53Z

    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

  13. Re: Optimization levels when compiling PostgreSQL...

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-09-10T14:03:09Z

    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

  14. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T15:30:30Z

    > > 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

  15. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T15:37:50Z

    > > 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

  16. Re: Optimization levels when compiling PostgreSQL...

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-09-10T15:57:34Z

    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

  17. Re: Optimization levels when compiling PostgreSQL...

    Sean Chittenden <sean@chittenden.org> — 2002-09-10T16:30:43Z

    > > 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

  18. Re: Optimization levels when compiling PostgreSQL...

    Peter Eisentraut <peter_e@gmx.net> — 2002-09-10T23:05:03Z

    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

  19. Re: Optimization levels when compiling PostgreSQL...

    Peter Eisentraut <peter_e@gmx.net> — 2002-09-10T23:05:20Z

    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

  20. Re: Optimization levels when compiling PostgreSQL...

    Curt Sampson <cjs@cynic.net> — 2002-09-11T01:31:06Z

    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 all light.  --XTC

  21. Re: Optimization levels when compiling PostgreSQL...

    Lamar Owen <lamar.owen@wgcr.org> — 2002-09-11T02:11:40Z

    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

  22. Re: Optimization levels when compiling PostgreSQL...

    Curt Sampson <cjs@cynic.net> — 2002-09-11T02:18:53Z

    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 all light.  --XTC

  23. Re: Optimization levels when compiling PostgreSQL...

    Florian Weimer <weimer@cert.uni-stuttgart.de> — 2002-09-23T05:44:54Z

    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