All of lore.kernel.org
 help / color / mirror / Atom feed
From: Howard Spoelstra <hsp.cat7@gmail.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Paul Clarke <pc@us.ibm.com>,
	Programmingkid <programmingkidx@gmail.com>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Date: Thu, 20 Feb 2020 06:43:18 +0100	[thread overview]
Message-ID: <CABLmASHhefWbz+wdbDmL_jLi9ad6HdWbEdFGc8f8Ei+Asy2fXw@mail.gmail.com> (raw)
In-Reply-To: <alpine.BSF.2.22.395.2002192001540.88848@zero.eik.bme.hu>

[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]

On Wed, Feb 19, 2020 at 8:28 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Wed, 19 Feb 2020, Howard Spoelstra wrote:
> > I tested with the current ppc-for-5.0 branch and with v1 of the hardfloat
> > patches applied on top of that. There is a noticeable speed improvement
> in
> > Linux and OSX hosts. Windows 10 host doesn't seem to be impressed at
> all. I
> > saw no obvious glitches so far. The fpu performance on OSX hosts seems
> very
> > slow. This was not always the case in the past, when it was on par with
> > Linux performance.
>
> Interesting, thanks for the measurements.
>
> > Below are my results.
> >
> > Best,
> > Howard
> >
> > Host Linux (Fedora 31):
> > Mac OS tests: 9.2 with MacBench 5.0
> > Baseline(100%): G3 300Mhz
> > 5.0 branch + hardfloat patches: cpu 193%, fpu 86%
> > 5.0 branch: cpu 188%, fpu 57%
>
> Here there's a difference in cpu value before and after patch which I
> can't explain (only changed FPU stuff so it should not change others) but
> also not seen in other measurements so this could be some external
> influence such as something else using CPU while running test? Unless this
> happens consistently I'd put it down to measurement error.
>

  Yes, I would put that cpu value down to some fluctuation in the test

>
> > Mac OSX tests: 10.5 with Skidmarks 4.0 test
> > Baseline(100%): G4 1.0Ghz.
> > 5.0 branch + hardfloat patches: Int:131 FP:11 Vec:15
> > 5.0 branch: Int:131 FP:9 Vec:11
> >
> > Host OSX Sierra:
> > Mac OS tests: 9.2 with MacBench 5.0
> > Baseline(100%): G3 300Mhz
> > 5.0 branch + hardfloat patches: cpu 199%, fpu 66%
> > 5.0 branch: cpu 199%, fpu 40%
> > Mac OSX tests: 10.5 with Skidmarks 4.0 test
> > Baseline(100%): G4 1.0Ghz.
> > 5.0 branch + hardfloat patches: Int:129 PF:11 Vec:14
>
> These values seem to match Linux measurement above so don't seem slower
> although MacOS9 seems to be slower (66 vs. 86) so either this depends on
> the ops used or something else.
>

 Yes, the baseline speed for the fpu in Mac OS 9.2 is relatively low.

>
> > 5.0 branch: Int:129 FP:8 Vec:9
> >
> > Host Windows 10:
> > Mac OS tests: 9.2 with MacBench 5.0
> > Baseline(100%): G3 300Mhz
> > 5.0 branch + hardfloat patches: cpu 180%, fpu 54%
>

 new run 5.0 branch + hardfloat patches: cpu 184%, fpu 54%

> 5.0 branch: cpu 199%, fpu 40%
>

 new run 5.0 branch: cpu 184%, fpu 56%

It seems I misreported (copy/past without changing the values) the earlier
Windows-based results with Mac OS 9.2 guest. As said above (and this now
seems to confirm) Windows is not impressed at all and perhaps a bit slower
even.
Windows builds are particularly sensitive to any other activity on the
system. Moving the qemu window drops performance considerably. Perhaps due
to SDL not running in its own thread?

>
> Here there's again difference in cpu value but the other way so maybe if
> the cause is external CPU usage then this again may be an outlying
> measurement? You could retake these two to verify if you get same numbers
> again. The fpu value does seem to improve just not as much as the others
> and it's also lower to start with. I wonder why.
>


> > Mac OSX tests: 10.5 with Skidmarks 4.0 test
> > Baseline(100%): G4 1.0Ghz.
> > 5.0 branch + hardfloat patches: Int:130 FP:9 Vec:10
> > 5.0 branch: Int:130 FP:10 Vec:11
> >
> > All tests done on the same host with v1 of the hardfloat patches
> > Intel i7-4770K at 3.50Ghz. 32Gb memory
> > All guests set to 1024x768 and "thousands" of colors.
>
> Does it mean this host machine were rebooted into these OSes or these were
> run in a VM. In case using VM, were all three running in VM or one was on
> host (I'd guess OSX host with Linux and Windows VMs).
>
> > Linux and OSX (with brew) use default compilers.
> > Windows build cross-compiled from Fedora with x86_64-win64-mingw32
>
> I assume Linux and OSX were 64 bit builds, is Windows 32 bit or 64 bit
> exe?
>

No virtualisation. I run all on the same bare metal, so booted into these
three separately from separate SSDs. You might guess OSX Sierra is running
on less "official" hardware and you would be right. All qemu builds were 64
bit.

Best,
Howard

[-- Attachment #2: Type: text/html, Size: 5760 bytes --]

  reply	other threads:[~2020-02-20  5:44 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
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 [this message]
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=CABLmASHhefWbz+wdbDmL_jLi9ad6HdWbEdFGc8f8Ei+Asy2fXw@mail.gmail.com \
    --to=hsp.cat7@gmail.com \
    --cc=balaton@eik.bme.hu \
    --cc=david@gibson.dropbear.id.au \
    --cc=pc@us.ibm.com \
    --cc=programmingkidx@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.