Subject: Re: kernel optimizations
To: Matthias Buelow <mkb@mukappabeta.de>
From: Sung N. Cho <sucho2@vt.edu>
List: netbsd-help
Date: 01/28/2002 13:37:16
Hi,  Matt

Thanks for the info.  Also, thanks to Steven Gruza for comment on -g option 
which answers why my kernels were 14Megs!  

Should I change the -O3 to -O2, comment out -g and keep the rest of the 
options without sacrificing the speed?

Here's my old mk.conf:
CFLAGS+=-O3 -march=i386 -mcpu=i686
CXXFLAGS=-O3 -march=i386 -mcpu=i686
COPTS+=-g -O3 -mcpu=i686 -fexpensive-optimizations -ffast-math -msoft-float \
		         -fmemoize-lookups -fthread-jumps -m486 -fomit-frame-pointer \
			 -finline-functions


Here's my new, modified mk.conf:
CFLAGS+=-O2 -march=i386 -mcpu=i686
CXXFLAGS=-O2 -march=i386 -mcpu=i686
COPTS+=-O2 -mcpu=i686 -fexpensive-optimizations -ffast-math -msoft-float \
		         -fmemoize-lookups -fthread-jumps -m486 -fomit-frame-pointer \
			 -finline-functions

Sung





On Monday 28 January 2002 06:31 pm, Matthias Buelow wrote:
> Sung N. Cho writes:
> >I have added the following optimizations in my mk.conf file.  I am not
> > sure if all these options are for optimizations since the man page for
> > gcc was poor in describing these.  If anyone sees that I've accidently
> > put any deoptimizing options, your comment would be appreciated.
> >
> >
> >CFLAGS+=-O3 -march=i386 -mcpu=i686
>
> [...]
>
> At least for the kernel, I'd leave "optimizations" as they are.
> Using -O3 for everything is generally bad anyways, since it might
> actually generate larger and slower code so it should only be used
> selectively after careful profiling (as is the case with higher
> optimization levels with any compiler.)  Highest code improvement
> options also have the tendency to move things around, eliminate or
> expand lots of code, which might confuse interfacing with some
> assembler parts or with device access code, so it's not too clever
> anyways to apply these options.  In the case of the kernel, even
> if it produced something correct in the end, you very likely won't
> notice any difference, since the kernel runs only in a fraction of
> the time and then most processing is I/O bound (and the time-
> consuming things are already quite optimized even for much slower
> CPUs than your i686 already.)
>
>   --mkb