Re: [avr-gcc-list] Whetstone Benchmark

[Andrew Hutchinson]

I was mistaken, I am using libc  l.6.1

I re-ran tests using simulavr and gdb and got exactly same results as 
AVRORA.  So the timing is right.

4.3 take different decision regarding inlining and loop unrolling - some 
good, some bad.
But these are controllable with compiler switches.

4.3 can be really smart, quite a lot of the testsuite cases get 
optimised into a simple exit(1) at O3
So benchmarks can be very problematic.

Unfortunately due to this I cant see if my changes have any good or bad 
effect until I create head version again
for direct comparison.

In 4.3 libc definition in maths.h are being included. (added about 30 
bytes) - think they got linked too!

Tried Winavr compiler with same setting and not sure what library 
version I have for 4.2
There is no way to tell after its built but I guess it might be 1.2
So instead look at  xlib as  size without library function

        text       xlib        cycles
Os     4540     2276     89824
O3     5690     3426     79875

4.3.0 (my version)
Os    4646     2378   87500
O3   6068     3800   75633 -fno-unit-at-a-time

All with:

-funsigned-char -fno-unit-at-a-time -funsigned-bitfields -fpack-struct 
-fshort-enums \
-Wall   -Wstrict-prototypes  -I$(DIRINC) \

All pretty meaningless really!



Andy H wrote:
> Here is figures I get from gcc head of yesterday and my development 
> build.
>
> The results are sensitive to build options so I
> do not know if difference are valid. I used AVRORA - which apparently 
> has good timing model.
> (I would have used Simulavr - but I have never used it to do this sort 
> of thing.)
>
> Sorry libc seems to be at 1.2.0 - I have not got around to updating 
> it. BUT how I can I check a build for library version info?????
>
>       .text      cycles
> Os    4646   87500
> O3   6068   75633 -fno-unit-at-a-time
> O3   5998   31752
>
> Why "unit at a time" compilation produced faster result ?  But the 
> code was totally inlined and perhaps it optimised out something that 
> it should not have for this purpose.
>
>
>
> Weddington, Eric wrote:
> >  
> >
> >  
> > > -----Original Message-----
> > > From: address@hidden 
> > > [mailto:address@hidden
> > > org] On Behalf Of Dmitry K.
> > > Sent: Monday, January 21, 2008 3:08 PM
> > > To: address@hidden
> > > Subject: Re: [avr-gcc-list] Whetstone Benchmark
> > >
> > > On Monday 21 January 2008 11:00, Weddington, Eric wrote:
> > >    
> > > > A couple of quick comments/suggestions:
> > > > - Please drop -morder1. We generally don't recommend this       
> > > to users, and
> > >    
> > > > it looks like it really doesn't affect the results that much
> > > > - Can you also try with avr-gc 4.2.2 and avr-libc 1.6.1?       
> > > These are the
> > >    
> > > > latest released versions.
> > > >       
> > > Flash  Cycles  Avr-gcc  Options
> > > -----  ------  -------  ----------------------
> > >  4296   88807    4.0.4  -Os
> > >  4484   80839    4.0.4  -O3
> > >  4030   88565    4.1.2  -Os
> > >  5332   71751    4.1.2  -O3
> > >  4194   89204    4.2.2  -Os
> > >  5388   72643    4.2.2  -O3
> > >  4350   86986    4.3.X  -Os
> > >  5608   75351    4.3.X  -O3 -fno-unit-at-a-time
> > >
> > >     
> >
> > Thanks again for doing this!
> >
> > Can you tell me how you measured code size and number of cycles?
> >
> > Thanks,
> > Eric Weddington
> >
> >
> > _______________________________________________
> > AVR-GCC-list mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> >