Re: Debug formats on Linux

[jfm2 at club-internet dot fr]

> 
> On Thu, Nov 02, 2000 at 10:29:49PM +0100, jfm2@club-internet.fr wrote:
> > 
> > > On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:
> > > 
> > > > I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> > > > well under 10%, and I think under 5%.  I found this funny since I
> > > > would expect an additional register woukld have a big impact on
> > > > register-starved x86s.  But unless omit-frame-pointer gives a far
> > > > bigger impact I would not want to go through yet another massive
> > > > change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> > > > the uncompatible C++ libraries from
> > > >  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3
> > > 
> > > fomit-frame-pointer gives better results to me, almost always around 
> > > 10%, notably with programs that are hard to speed up otherwise. That 
> > > is for x86 and m68k, 2.7.2.3, 2.8.[01], 2.95.*.
> > > 
> > 
> > What were the other parms?  My method was: start from "-O2)
> > -mcpu=pentiumpro" (later I redid it with "-O2 -march=pentiumpro" and
> > then successively apply every parm and look for the one giving the
> > bigger increase (inline-functions) and take the new flag set
> > (equivalent to -03 -mcpu=i686) as a new starting point.  The fact I
> > was optimizing for the P6 core instead of plain 386 and the fact I was
> > at O3 optimization level can have an influence.  I have noticed some
> > strange synergies during my tests: some parms have little or no effect
> > if some other parm is not present, in other occasions a parm who used
> > to have a positive effect has anegative effect if some other is
> > active.
> > 
> > This could explain the differences between our results.
> 
> The differences can be probably explained with function sizes etc.
> It is a m68k emulator and inlining everything hurts cahces so there
> are some quite small functions.
> Also I have used all other tricks like inline assembly, using register
> parameters for some functions and always optimise for the exact chip.
> 
> Bye
> Richard
> 
> 


According to doc -finline-function does not inline everything only
small functions.  But I agree about -O3 being a double edged sword
duie to code size increase.

I was using the byte benchamrk.  I also noticed thazt on some tests
cpu=pentiumpro was faster than arch=pentiumpro, and on the FP
emulation test cpu=i386 beats cpu=i686 or arch=i686 by around 20%.
This suggests that there is something wrong with the 2.95 optimizer.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org