qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 00/14] fp-test + hostfloat


From: Emilio G. Cota
Subject: Re: [Qemu-devel] [PATCH v1 00/14] fp-test + hostfloat
Date: Thu, 22 Mar 2018 11:28:40 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Mar 22, 2018 at 08:56:36 +0000, Alex Bennée wrote:
> 
> Emilio G. Cota <address@hidden> writes:
> 
> <snip>
> > For performance numbers see the last patch.
> 
> Just another random data point as we've been using himeno for our SVE
> wor:
> 
> Master:
> 
> 8:05:45  address@hidden:~/l/q/qemu.git] master ± 
> ./aarch64-linux-user/qemu-aarch64 sve.demo/himeno-v80
> mimax = 129 mjmax = 65 mkmax = 65
> imax = 128 jmax = 64 kmax =64
> cpu : 33.430299 sec.
> Loop executed for 200 times
> Gosa : 1.688752e-03
> MFLOPS measured : 98.519585
> Score based on MMX Pentium 200MHz : 3.052978
> 
> Host FPU:
> 
> 08:25:03 address@hidden:~/l/q/qemu.git] master ± 
> ./aarch64-linux-user/qemu-aarch64 sve.demo/himeno-v80
> mimax = 129 mjmax = 65 mkmax = 65
> imax = 128 jmax = 64 kmax =64
> cpu : 15.067773 sec.
> Loop executed for 200 times
> Gosa : 1.688752e-03
> MFLOPS measured : 218.581684
> Score based on MMX Pentium 200MHz : 6.773526
> 
> Given SVE also beats v80 code thanks to avoiding marshalling overhead by
> doing bigger vectors I expect that improvement to be even better. Once
> the SVE patches are re-based I'll measure them.

This is nice to see. It is possible though that this code uses other FP
instructions that this patchset doesn't speed up; perf record/report
will point to those, if any.

> By the way I've been talking to some of the people at connect about
> tracking performance over time. I got pointed to LLVM's LNT tool
> (example: https://lnt.llvm.org/) so I might see if I can get a server
> set up that we can start pushing numbers to. Have you come across any
> other such things?

I like the idea of having a server to test for performance regressions.

Perhaps the hardest bit would be to choose what benchmarks to run.
We could start with nbench and (parallel w/ MTTCG) bootup+shutdown
tests, although having access to SPEC (it's proprietary) would be nice;
as you can see below I think SPEC has a better job than nbench at
characterizing performance.

I have scripts for automatically generating perf numbers and plots;
I could share those. With them, generating plots like the following
is trivial (if you discount the time it takes for the tests to run,
heh):
  https://imgur.com/a/5P5zj
  context:
  http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg01206.html

Thanks,

                Emilio



reply via email to

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