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