Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

[Konstantinos Margaritis <markos@genesi-usa.com>]

On Friday 16 July 2010 00:29:27 Paul Brook wrote:
> A simple benchmark confirms this hypothesis.
> softfp is actually faster in many cases.

<snip>

If you want to do a benchmark on sinf, next time do it right, span the values 
on 0..M_PI at least (not 0..1.0), here are the results with only one change:

23: y[i] = M_PI* i / (float) N;

You obviously are knowledgable enough to work a benchmark that works faster on 
softfp, but you were wrong with sinf (results from time, real value):

//x[i] = sinf(y[i]); // hard 15% slower
softfp: 0m4.975s, hard: 0m5.222s, hardfp actually 10% slower

//x[i] = sinf(y[i]) + 1.0; // hard 5% slower
softfp:0m5.341s, hard: 0m5.325s, not really a difference here

//x[i] = sinf(y[i] + 1.0); // hard 0.5% slower
softfp: 0m6.347s, hard: 0m6.033s, hardfp 5% faster

//x[i] = sinf(y[i] + 1.0) + 1.0; // softfp 2.5% slower
softfp: 0m6.842s, hard: 0m6.222s, hardfp 10% faster

So, what exactly did you want to prove? That softfp is better? yes, in some 
cases. What about the other cases? Anyway, I'm not discussing if it's better 
or not, for *our* needs it's more than better, it's the proper way of using an 
FPU -all arches use it that way, about time ARM starts using it right too.

Konstantinos