qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.



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