On 16 January 2012 00:46, Andreas Färber <afaer...@suse.de> 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 <peter.mayd...@linaro.org> 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 :-) -- PMM
