From: Programmingkid <programmingkidx@gmail.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>,
qemu-ppc@nongnu.org, Paul Clarke <pc@us.ibm.com>,
Howard Spoelstra <hsp.cat7@gmail.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Date: Tue, 18 Feb 2020 21:27:28 -0500 [thread overview]
Message-ID: <CD566CEF-6844-455C-B9C7-E5DFDE50E770@gmail.com> (raw)
In-Reply-To: <20200218171702.979F074637D@zero.eik.bme.hu>
> On Feb 18, 2020, at 12:10 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> While other targets take advantage of using host FPU to do floating
> point computations, this was disabled for PPC target because always
> clearing exception flags before every FP op made it slightly slower
> than emulating everyting with softfloat. To emulate some FPSCR bits,
> clearing of fp_status may be necessary (unless these could be handled
> e.g. using FP exceptions on host but there's no API for that in QEMU
> yet) but preserving at least the inexact flag makes hardfloat usable
> and faster than softfloat. Since most clients don't actually care
> about this flag, we can gain some speed trading some emulation
> accuracy.
>
> This patch implements a simple way to keep the inexact flag set for
> hardfloat while still allowing to revert to softfloat for workloads
> that need more accurate albeit slower emulation. (Set hardfloat
> property of CPU, i.e. -cpu name,hardfloat=false for that.) There may
> still be room for further improvement but this seems to increase
> floating point performance. Unfortunately the softfloat case is slower
> than before this patch so this patch only makes sense if the default
> is also set to enable hardfloat.
>
> Because of the above this patch at the moment is mainly for testing
> different workloads to evaluate how viable would this be in practice.
> Thus, RFC and not ready for merge yet.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> v2: use different approach to avoid needing if () in
> helper_reset_fpstatus() but this does not seem to change overhead
> much, also make it a single patch as adding the hardfloat option is
> only a few lines; with this we can use same value at other places where
> float_status is reset and maybe enable hardfloat for a few more places
> for a little more performance but not too much. With this I got:
<snip>
Thank you for working on this. It is about time we have a better FPU.
I applied your patch over David Gibson's ppc-for-5.0 branch. It applied cleanly and compiled easily.
Tests were done on a Mac OS 10.4.3 VM. The CPU was set to G3.
I did several tests and here are my results:
With hard float:
- The USB audio device does not produce any sound.
- Converting a MIDI file to AAC in iTunes happens at 0.4x (faster than soft float :) ).
For my FPSCR test program, 21 tests failed. The high number is because the inexact exception is being set for situations it should not be set for.
With soft float:
- Some sound can be heard from the USB audio device. It isn't good sounding. I had to force quit Quicktime player because it stopped working.
- Converting a MIDI file to AAC in iTunes happens at 0.3x (slower than hard float).
- 13 tests failed with my FPSCR test program.
This patch is a good start. I'm not worried about the Floating Point Status and Control Register flags being wrong since hardly any software bothers to check them. I think more optimizations can happen by simplifying the FPU. As it is now it makes a lot of calls per operation.
next prev parent reply other threads:[~2020-02-19 2:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 17:10 [RFC PATCH v2] target/ppc: Enable hardfloat for PPC BALATON Zoltan
2020-02-18 17:38 ` BALATON Zoltan
2020-02-19 2:27 ` Programmingkid [this message]
2020-02-19 15:35 ` BALATON Zoltan
2020-02-19 18:28 ` Howard Spoelstra
2020-02-19 19:28 ` BALATON Zoltan
2020-02-20 5:43 ` Howard Spoelstra
2020-02-25 3:07 ` Programmingkid
2020-02-25 12:09 ` BALATON Zoltan
2020-02-26 10:46 ` Programmingkid
2020-02-26 11:28 ` BALATON Zoltan
2020-02-26 13:00 ` R: " luigi burdo
2020-02-26 13:08 ` Dino Papararo
2020-02-26 14:28 ` Alex Bennée
2020-02-26 15:50 ` Aleksandar Markovic
2020-02-26 17:04 ` G 3
2020-02-26 17:27 ` Aleksandar Markovic
2020-02-26 18:14 ` R: " Dino Papararo
2020-02-26 18:51 ` Aleksandar Markovic
2020-02-27 2:43 ` Programmingkid
2020-02-27 7:16 ` Aleksandar Markovic
2020-02-27 11:54 ` BALATON Zoltan
2020-02-26 18:09 ` R: " Alex Bennée
2020-03-02 0:13 ` Programmingkid
2020-03-02 4:28 ` Richard Henderson
2020-03-02 11:42 ` BALATON Zoltan
2020-03-02 16:55 ` Richard Henderson
2020-03-02 23:16 ` BALATON Zoltan
2020-03-03 0:11 ` Richard Henderson
[not found] ` <CAKyx-3Pt2qLPXWQjBwrHn-nxR-9e++TioGp4cKFC3adMN3rtiw@mail.gmail.com>
2020-03-04 18:43 ` Fwd: " G 3
2020-03-05 19:25 ` Richard Henderson
2020-03-02 17:10 ` Alex Bennée
2020-03-02 23:01 ` BALATON Zoltan
2020-02-26 22:51 ` R: " BALATON Zoltan
2020-02-20 20:13 ` Richard Henderson
2020-02-21 16:04 ` BALATON Zoltan
2020-02-21 16:11 ` Peter Maydell
2020-02-21 16:51 ` Aleksandar Markovic
2020-02-21 18:04 ` BALATON Zoltan
2020-02-21 18:26 ` Peter Maydell
2020-02-21 19:52 ` BALATON Zoltan
2020-02-26 12:28 ` Alex Bennée
2020-02-26 13:07 ` BALATON Zoltan
2020-04-10 13:50 ` 罗勇刚(Yonggang Luo)
2020-04-10 18:04 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD566CEF-6844-455C-B9C7-E5DFDE50E770@gmail.com \
--to=programmingkidx@gmail.com \
--cc=balaton@eik.bme.hu \
--cc=david@gibson.dropbear.id.au \
--cc=hsp.cat7@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=pc@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).