Debug formats on Linux

[jfm2@club-internet.fr]

> 
> On Fri, Nov 03, 2000 at 08:50:56AM +0100, jfm2@club-internet.fr wrote:
> 
> [..snip..]
> 
> > 
> > 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.
> 
> sure, I never use -O3 for my own programs - it is much better to use
> the inline keyword where apropriate and -funroll-loops where it helps.
> 
> > 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.
> 
> benchmarks aren't good for my purposes, they test the optimizer on 
> "average" code. Very often the most performance critical code will 
> be already programmed for speed so it has little common with average
> code.

The byte benchmark is supposed to be not an artificial benchmark but
one made of problems who are frequently found in practice like
decomposition in Fourier series.  Problem is that world is not as
simple that in the good old times of 386.  In those days you could
take results of a benchmerk exerting instruction A and of benchmark
exerting instruction B and deduce results on progrem mixing A and B
instructions.  This is no longer true.

As an example consider the plain Pentium with its two asymetric
integer pipelines only one them being able to excute complex
instructions like multiplications.  It could happen that for comparing
two compilers you run a benchmark and find they get identical results
on both the test exerting simple instructions and on the test exerting
multiplication and division.  However once you compile normal code who
mixes simple and complex instructions you could find that compiler A
is not smart enough to account for the asymetric nature of the Pentium
so in many occasions a multiplication will be waiting because an
addition is using the U (universal) pipeline while the V one (unusable
for multiplication) is empty.  Thus if compiler B is smart enough to
manage that multiplications will ever find a V pipeline busy with
simple instructions and an empty U pipeline then code generated by B
will be much faster than code generated by A on mixed instruction (ie
typical) programs despite the fact they are equivalent on code
exerting a single type of instructions

This illustrates how necessary it is to understand the limits of a
benchmark when analyzing its results

> Mostly I found march=chip produce faster but often bigger code.
> 

But unless you know your code will run on only one computer you rarely
can use -arch.  For instance the K6 family will not accept code
compiled with -arch=i686 and fast K6/2s beat the pants of equally
priced PIIs in integer-intensive code so you cannot discard as
obsolete those processors accepting only the P5 instuction set.  And
I can tell you (I have one) a K6/2 is significantly faster on code
compiled with -mcpu=i686 than on code compiled with -march=i586.
Compiler was gcc 2.95.2

-- 
			Jean Francois Martinez

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