Re: [MiNT] MiNT lib 55

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

On Sun, May 14, 2000 at 02:10:06AM +0300, Martin-Éric Racine wrote:
> > I don't think that an 030 kernel is a lot faster than a plain
> > 68000 kernel.
> 
> It definitely _is_ faster, as my previous experiences show.
> Because of that, -m68030 optimization should _never_ be thined
> down to 68000 code.

I haven't done extensive kernel benchmarking as you seem to have but I
haven't noticed a significant performance gap.

> > The RPM binary is only by accident compiled with -m68020-60
> 
> Which was never fixed, thus preventing people without a 020+FPU
> or better from using it.

Right. Frank, can you replace the rpm binary with mine in the
bootstrapping archive?

> > default flags for Sparemint packages are "-O2 -fomit-frame-pointer".
> 
> Noted.  Btw, what is the advantage of using -fomit-frame-pointer?

It doesn't store the frame pointer in a register when it is not needed for
running the program.  Thus one register is often saved (and free to
use for other purposes) and the code to save/restore the frame pointer can
also be omitted.  The disadvantage of this is that debugging is prevented
in certain cases but that doesn't count for production releases. 

> > > > I doubt that you will gain a lot by only giving -m68020-60.  
> 
> Well, Frank's specs transform that into 020-040 plus FPU.

And the implied -m68881 is meaningless for the kernel, see below.

> > Does that mean that you have decided to become the darling of
> > this list and be a nice guy with everybody?
> 
> Nope.  Only that, after stating so many times that you don't see
> the point in my using FPU optimization, you and Frank nonetheless
> ended up hacking to the specs to generate FPU-enabled code when
> -m68020-60 is used.

And you have been taught countless times that the kernel doesn't do any
floating point arithmetics.

> > P.S.: In a previous posting you have mentioned that you
> > compile your kernel yourself because you prefer to optimize
> > with -O3.  That can be an explanation for the astonishing
> > amount of unreproducable bugs you report.  Exaggerating
> > optimization is a common source of errors, especially in
> > "sensitive" software like the kernel.
> > 
> > You should always keep a kernel compiled with the default
> > flags and test if it shows the same behavior as your
> > self-built kernel.
> 
> Clean code always compiles well with -O3.  The resulting binary
> is often slightly larger than those produced with -O2 or lesser
> optimization, but the speed increase is noticable.

The question is not whether it compiles.  The question is whether the
resulting binary works like intended.

Anyway, you shouldn't make such a statement if you don't even know the
effect of the most common optimizations like -fomit-frame-pointer.  
Besides, it is pure nonsense.  You can make a lot of clean code crash by
over-optimization.  Even -O2 is often too much.  Optimizing always bears
the risk of introducing bugs.  Mixing up high-level language code with
assembler (like it is inevitable in a kernel) increases these risks.

BTW, unless the inlining strategy in the kernel has been fixed, it is
impossible to compile (resp. link) the kernel without any optimization.  
You will always need at least -O (just in case somebody wants to save time
or track down errors by turning off all optimization).

Ciao

Guido
-- 
http://www.stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de