Re: [Qemu-devel] [PATCH 00/14] softfloat: Use POSIX integer types - benchmarked

[Alexander Graf]

On 16.01.2012, at 20:02, Peter Maydell wrote:

> On 16 January 2012 00:46, Andreas Färber <address@hidden> wrote:
>> Based on a suggestion from Alex earlier this week, I managed to run a
>> simple benchmark of softfloat performance with qemu-arm, as requested by
>> Peter.
>> 
>> I went for the Whetstone floating point benchmark:
>> http://en.wikipedia.org/wiki/Whetstone_%28benchmark%29
>> 
>> For a loop count of 100,000 and 5 runs I got the following results:
>> 
>>  current:        138.9-204.1 Whetstone-MIPS
>>  [u]int*_t:      185.2-188.7 Whetstone-MIPS
>>  [u]int_fast*_t: 285.7-294.1 Whetstone-MIPS
>> 
>>  Toshiba AC100:  833.3-909.1 Whetstone-MIPS
> 
> This is much better than I was expecting when I suggested running
> a benchmark :-) and indicates that it's worth a bit of pain to
> switch to the fast* types.
> 
> I've tested this series with the ARM VFP/Neon tests I have (random
> instruction sequence testing). I found a few extra bugs which I've
> sent a separate patch series for: those patches need to be
> incorporated into this series or otherwise applied before it.
> 
> I've commented on patches 01, 05, 09; the rest are
> Reviewed-by: Peter Maydell <address@hidden>
> 
> with the following caveat.
> 
> The changes from int32/uint32 to int_fast32_t/uint_fast32_t are
> the potentially dangerous ones in this set, since they change a
> type that was easily mistaken for "exactly 32 bits" and happened
> to be 32 bits to one that is now 64 bits (on 64 bit hosts).
> The other type changes are either "not a width change in practice"
> (int64) or "change from something that was already wider than the
> number in it" (int16) or "wasn't being used for things where we
> really cared about the type width" (int8, flag).
> 
> Specifically, it's this change that revealed the latent bugs I
> sent a three-patch set for, and so it doesn't seem too unlikely
> that other platforms may have some similar bugs in their
> int-to-float/float-to-int code that will now be revealed on
> 64 bit hosts.
> 
> I don't think that means we shouldn't apply this patch set but
> I would recommend some testing of other architectures :-)

So what if we leave uint32_t be uint32_t and make the other ones _fast_?


Alex