Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH 0/6] target/ppc: convert VMX instructions to use TCG vector operations

[David Gibson <david@gibson.dropbear.id.au>]

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

On Mon, Dec 10, 2018 at 09:54:51PM +0100, BALATON Zoltan wrote:
> On Mon, 10 Dec 2018, David Gibson wrote:
> > On Mon, Dec 10, 2018 at 01:33:53AM +0100, BALATON Zoltan wrote:
> > > On Fri, 7 Dec 2018, Mark Cave-Ayland wrote:
> > > > This patchset is an attempt at trying to improve the VMX (Altivec) instruction
> > > > performance by making use of the new TCG vector operations where possible.
> > > 
> > > This is very welcome, thanks for doing this.
> > > 
> > > > In order to use TCG vector operations, the registers must be accessible from cpu_env
> > > > whilst currently they are accessed via arrays of static TCG globals. Patches 1-3
> > > > are therefore mechanical patches which introduce access helpers for FPR, AVR and VSR
> > > > registers using the supplied TCGv_i64 parameter.
> > > 
> > > Have you tried some benchmarks or tests to measure the impact of these
> > > changes? I've tried the (very unscientific) benchmarks I've written about
> > > before here:
> > > 
> > > http://lists.nongnu.org/archive/html/qemu-ppc/2018-07/msg00261.html
> > > 
> > > (which seem to use AltiVec/VMX instructions but not sure which) on mac99
> > > with MorphOS and I could not see any performance increase. I haven't run
> > > enough tests but results with or without this series on master were mostly
> > > the same within a few percents, and sometimes even seen lower performance
> > > with these patches than without. I haven't tried to find out why (no time
> > > for that now) so can't really draw any conclusions from this. I'm also not
> > > sure if I've actually tested what you've changed or these use instructions
> > > that your patches don't optimise yet, or the changes I've seen were just
> > > normal changes between runs; but I wonder if the increased number of
> > > temporaries could result in lower performance in some cases?
> > 
> > What was your host machine.  IIUC this change will only improve
> > performance if the host tcg backend is able to implement TCG vector
> > ops in terms of vector ops on the host.
> 
> Tried it on i5 650 which has: sse sse2 ssse3 sse4_1 sse4_2. I assume x86_64
> should be supported but not sure what are the CPU requirements.
> 
> > In addition, this series only converts a subset of the integer and
> > logical vector instructions.  If your testcase is mostly floating
> > point (vectored or otherwise), it will still be softfloat and so not
> > see any speedup.
> 
> Yes, I don't really know what these tests use but I think "lame" test is
> mostly floating point but tried with "lame_vmx" which should at least use
> some vector ops and "mplayer -benchmark" test is more vmx dependent based on
> my previous profiling and testing with hardfloat but I'm not sure. (When
> testing these with hardfloat I've found that lame was benefiting from
> hardfloat but mplayer wasn't and more VMX related functions showed up with
> mplayer so I assumed it's more VMX bound.)

I should clarify here.  When I say "floating point" above, I'm not
meaning things using the regular FPU instead of the vector unit.  I'm
saying *anything* involving floating point calculations whether
they're done in the FPU or the vector unit.

The patches here don't convert all VMX instructions to use vector TCG
ops - they only convert a few, and those few are about using the
vector unit for integer (and logical) operations.  VMX instructions
involving floating point calculations are unaffected and will still
use soft-float.

> I've tried to do some profiling again to find out what's used but I can't
> get good results with the tools I have (oprofile stopped working since I've
> updated my machine and Linux perf provides results that are hard to
> interpret for me, haven't tried if gprof would work now it didn't before)
> but I've seen some vector related helpers in the profile so at least some
> vector ops are used. The "helper_vperm" came up top at about 11th (not sure
> where is it called from), other vector helpers were lower.
> 
> I don't remember details now but previously when testing hardfloat I've
> written this: "I've looked at vperm which came out top in one of the
> profiles I've taken and on little endian hosts it has the loop backwards and
> also accesses vector elements from end to front which I wonder may be enough
> for the compiler to not be able to optimise it? But I haven't checked
> assembly. The altivec dependent mplayer video decoding test did not change
> much with hardfloat, it took 98% compared to master so likely altivec is
> dominating here." (Although this was with the PPC specific vector helpers
> before VMX patch so not sure if this is still relevant.)
> 
> The top 10 in profile were still related to low level memory access and MMU
> management stuff as I've found before:
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg03609.html
> http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg03704.html
> 
> I think implementing i2c for mac99 may help this and some other
> optimisations may also be possible but I don't know enough about these to
> try that.
> 
> It also looks like with --enable-debug something is always flusing tlb and
> blowing away tb caches so these will be top in profile and likely dominate
> runtime so can't really use profile to measure impact of VMX patch. Without
> --enable-debug I can't get call graphs so can't get useful profile. I think
> I've looked at this before as well but can't remember now which check
> enabled by --enable-debug is responsible for constant tb cache flush and if
> that could be avoided. I just don't use --enable-debug since unless need to
> debug somthing.
> 
> Maybe the PPC softmmu should be reviewed and optimised by someone who knows
> it...

I'm not sure there is anyone who knows it at this point.  I probably
know it as well as anybody, and the ppc32 code scares me.  It's a
crufty mess and it would be nice to clean up, but that requires
someone with enough time and interest.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]