On 16.01.2012, at 20:02, Peter Maydell wrote: > 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 :-)
So what if we leave uint32_t be uint32_t and make the other ones _fast_? Alex