qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 00/14] softfloat: Use POSIX integer types - benchmarked
Date: Mon, 16 Jan 2012 19:02:08 +0000

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 :-)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]