qemu-ppc
[Top][All Lists]
Advanced

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

Re: [RFC PATCH 0/4] Idea for using hardfloat in PPC


From: Alex Bennée
Subject: Re: [RFC PATCH 0/4] Idea for using hardfloat in PPC
Date: Fri, 07 Oct 2022 14:42:55 +0100
User-agent: mu4e 1.9.0; emacs 28.2.50

Richard Henderson <richard.henderson@linaro.org> writes:

> On 10/5/22 07:37, Víctor Colombo wrote:
>> However, the impact in performance was not the expected. In x86_64 I
>> had a small 3% improvement, while in a Power9 machine there was a small
>> performance loss, as can be seem below (100 executions).
>> |        | min [s] | max [s] | avg [s] |
>> | before | 122.309 | 123.459 | 122.747 |
>> | after  | 123.906 | 125.016 | 124.373 |
>
> I hope this is because you didn't handle the most common cases: add, sub, 
> mul, div.
>
> The logic seems plausible, as far as it goes, and would work for the
> FR bit as well which afair isn't handled at all at the moment.  I'll
> review properly in a little while.

I wonder if this is something that could be generalised and pushed up
into the fpu stuff itself. We could after all cache the op and
decomposed parameters here in a generic way. The trick would be working
out how to do that without slowing down the current common case.

Is ppc unique in not persisting the inexact flag from previous
operations?

>
>
> r~


-- 
Alex Bennée



reply via email to

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