Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Friday 16 July 2010 00:29:27 Paul Brook wrote:
> A simple benchmark confirms this hypothesis.
> softfp is actually faster in many cases.
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.