Is there any risk using -O3 instead of -O2 to compile the kernel, and why?
Also what about compiling against glibc 2.3.1 and gcc 3.2.x??
Thanks!
--Ro0tSiEgE
> Is there any risk using -O3 instead of -O2 to compile the kernel, and why?
* It might uncover subtle bugs that would otherwise not occur.
* Compiling with unusual options means that less people will know about
any problems it causes you.
> Also what about compiling against glibc 2.3.1 and gcc 3.2.x??
The kernel does not use glibc functions, so you can compile the kernel
and glibc with different compilers.
Bug reports about GCC 3.2.x compiled kernels will probably be welcomed
by most developers.
John.
Hi Ro0tSiEgE!
On Sat, 21 Dec 2002, Ro0tSiEgE wrote:
> Is there any risk using -O3 instead of -O2 to compile the kernel, and why?
> Also what about compiling against glibc 2.3.1 and gcc 3.2.x??
I believe because of some assembler stuff that needs to be compiled as is and
may not be optimized more that -O2 you cannot use -O3.
There is no problem compiling the kernel with glibc 2.3.1 and gcc 3.2.x.
Axel
> > Is there any risk using -O3 instead of -O2 to compile the kernel, and why?
> > Also what about compiling against glibc 2.3.1 and gcc 3.2.x??
> I believe because of some assembler stuff that needs to be compiled as is and
> may not be optimized more that -O2 you cannot use -O3.
Then selective compile with -O2 or -O6? Like; everything with assembly in
it with -O2 and the rest with -O6.
Folkert
http://www.vanheusden.com/Linux
> > Is there any risk using -O3 instead of -O2 to compile the kernel, and why?
> * It might uncover subtle bugs that would otherwise not occur.
I wonder: for the sake of performance and good use of the precious clock-
cycles, shouldn't there be made a start of fixing those bugs? Assuming
that the bugs you're talking about are not compiler-bugs, they *are* bugs
in the code that should be fixed, shouldn't they?
> * Compiling with unusual options means that less people will know about
> any problems it causes you.
So, let's make it -O6 per default for 2.7.x/3.1.x?
Folkert
http://www.vanheusden.com/Linux
> > > Is there any risk using -O3 instead of -O2 to compile the
> > > kernel, and why?
> > * It might uncover subtle bugs that would otherwise not occur.
> I wonder: for the sake of performance and good use of the precious clock-
> cycles, shouldn't there be made a start of fixing those bugs? Assuming
> that the bugs you're talking about are not compiler-bugs, they *are* bugs
> in the code that should be fixed, shouldn't they?
There obviously are bugs in GCC, and the kernel team work around the
known ones. This is part of the reason that there is a recommended
compiler version. The Linux kernel also uses GCC compiler extensions,
and those can change between GCC versions.
The kernel has bugs too, but if they are not triggered by the
recommended version of GCC, then they might not get fixed immediately,
especially if the fix is non-trivial.
> > * Compiling with unusual options means that less people will know about
> > any problems it causes you.
>
> So, let's make it -O6 per default for 2.7.x/3.1.x?
A higher -O setting does not necessarily mean better performance -
loop unrolling is one compiler optimisation that I *think* is
performed by GCC at high -O settings, and that *often* causes code to
be slower.
John.
On Saturday 21 December 2002 04:10 pm, [email protected] wrote:
> > > Is there any risk using -O3 instead of -O2 to compile the
> > > kernel, and why?
> >
> > * It might uncover subtle bugs that would otherwise not occur.
>
> I wonder: for the sake of performance and good use of the precious
> clock- cycles, shouldn't there be made a start of fixing those
> bugs? Assuming that the bugs you're talking about are not
> compiler-bugs, they *are* bugs in the code that should be fixed,
> shouldn't they?
>
> > * Compiling with unusual options means that less people will know
> > about any problems it causes you.
>
> So, let's make it -O6 per default for 2.7.x/3.1.x?
Let's not. I'd rather have the best kernel developers concentrating on
finishing important kernel features rather than digging their way out
of esoteric optimizer debugging sessions only to find it was a flaw
in gcc. The difference in performance boost between -O2 and greater
levels isn't usually enough to make a significant impact, not as
significant as the introduction of important new features, for
example.
---scott
Em Sat, Dec 21, 2002 at 07:20:28PM -0600, scott thomason escreveu:
> On Saturday 21 December 2002 04:10 pm, [email protected] wrote:
> > > > Is there any risk using -O3 instead of -O2 to compile the
> > > > kernel, and why?
> > >
> > > * It might uncover subtle bugs that would otherwise not occur.
> >
> > I wonder: for the sake of performance and good use of the precious
> > clock- cycles, shouldn't there be made a start of fixing those
> > bugs? Assuming that the bugs you're talking about are not
> > compiler-bugs, they *are* bugs in the code that should be fixed,
> > shouldn't they?
> >
> > > * Compiling with unusual options means that less people will know
> > > about any problems it causes you.
> >
> > So, let's make it -O6 per default for 2.7.x/3.1.x?
>
> Let's not. I'd rather have the best kernel developers concentrating on
> finishing important kernel features rather than digging their way out
> of esoteric optimizer debugging sessions only to find it was a flaw
> in gcc. The difference in performance boost between -O2 and greater
> levels isn't usually enough to make a significant impact, not as
> significant as the introduction of important new features, for
> example.
Sometimes even _reducing_ the optimization for performance level makes it
faster, try with -Os. And this was already discussed here and elsewhere,
reading the archives would help a lot avoiding adding more noise to the list.
- Arnaldo
On Sat, 2002-12-21 at 17:10, [email protected] wrote:
> So, let's make it -O6 per default for 2.7.x/3.1.x?
Maybe if we hate our instruction cache..
Robert Love
> > So, let's make it -O6 per default for 2.7.x/3.1.x?
>
> A higher -O setting does not necessarily mean better performance -
> loop unrolling is one compiler optimisation that I *think* is
> performed by GCC at high -O settings, and that *often* causes code to
> be slower.
In all official releases of GCC, -Ox, x >= 4, has exactly the same
effect as -O3. This is unlikely to change anytime soon.
-O3 enables exactly two optimizations relative to -O2:
-finline-functions and -frename-registers. This may or may not change
in the future. It does *not* enable loop unrolling. -finline-functions
is almost always a major performance loss, because it makes the code
huge and blows out the I-cache. I'm not familiar with the performance
effects of -frename-registers; it might be worth experimenting with
just that switch.
zw
On Sat, 21 Dec 2002, Zack Weinberg wrote:
>
> > > So, let's make it -O6 per default for 2.7.x/3.1.x?
> >
> > A higher -O setting does not necessarily mean better performance -
> > loop unrolling is one compiler optimisation that I *think* is
> > performed by GCC at high -O settings, and that *often* causes code to
> > be slower.
>
> In all official releases of GCC, -Ox, x >= 4, has exactly the same
> effect as -O3. This is unlikely to change anytime soon.
>
> -O3 enables exactly two optimizations relative to -O2:
> -finline-functions and -frename-registers. This may or may not change
> in the future. It does *not* enable loop unrolling. -finline-functions
> is almost always a major performance loss, because it makes the code
> huge and blows out the I-cache. I'm not familiar with the performance
> effects of -frename-registers; it might be worth experimenting with
> just that switch.
>
Why do I see all the time using >O3 when in the gcc man/docs they say the
max Ox is 3 and above that it is assumed that is O3?
-finline-functions makes a difference in C++ 8) but the number of inline
functions can be defined with finline-limit.Could you be more specific
about the major performance loss?
Rename registers from the gcc 3.2 man:
"Attempt to avoid false dependencies in scheduled code by making
use of registers left over after register allocation. This
optimization will most benefit processors with lots of
registers. It can, however, make debugging impossible, since
variables will no longer stay in a "home register"."
Making debugging impossible could be a problem in the kernel apart from
the performance :)
Best Regards,
Joao Seabra
On Sun, Dec 22, 2002 at 01:23:08PM +0000, Joao Seabra wrote:
> Rename registers from the gcc 3.2 man:
> "Attempt to avoid false dependencies in scheduled code by making
> use of registers left over after register allocation. This
> optimization will most benefit processors with lots of
> registers. It can, however, make debugging impossible, since
> variables will no longer stay in a "home register"."
Just to be blunt here :), i386 is not one of these register rich
archs. So it will probably not help you to compile with -O3... Of course
you could have something else...
- Adam