permissions: 0.953
TCG: 0.928
peripherals: 0.925
register: 0.920
mistranslation: 0.916
performance: 0.906
graphic: 0.897
device: 0.892
architecture: 0.872
user-level: 0.858
debug: 0.855
arm: 0.854
boot: 0.847
socket: 0.846
ppc: 0.844
risc-v: 0.843
hypervisor: 0.843
VMM: 0.838
files: 0.823
semantic: 0.821
assembly: 0.814
network: 0.782
kernel: 0.768
PID: 0.757
virtual: 0.720
vnc: 0.665
x86: 0.661
KVM: 0.641
i386: 0.620

SIMD instructions translated to scalar host instructions

SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions.  It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2].

I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM).

[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html

On 19 June 2016 at 06:33, Timothy Pearson <email address hidden> wrote:
> Public bug reported:
>
> SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are
> translated to scalar instructions on the host instead of SIMD
> instructions.  It appears that there have been a few efforts to rectify
> this [1], and even a submitted patch series, but all discussion has
> effectively died out [2].
>
> I would like to see better SIMD performance on qemu, especially as
> non-x86 architectures are becoming widely used (e.g. ARM).

I agree it would be nice, but I'm not sure there's much benefit
from filing a bug about it. Bug reports don't magically become
code changes, and doing SIMD-to-SIMD is very difficult when
you need to support multiple host and guest architectures and
get all the details and corner cases correct. QEMU as it stands
isn't behaving wrongly.

thanks
-- PMM


I mostly filed the bug report since I was seeing multiple different attempts to implement this, and even a proper patch series on the mailing list, but no movement at all toward integrating this feature into mainline qemu.

What would be needed to e.g. make the patch series on the mailing list acceptable for merge?

On 20 June 2016 at 15:05, Timothy Pearson <email address hidden> wrote:
> I mostly filed the bug report since I was seeing multiple different
> attempts to implement this, and even a proper patch series on the
> mailing list, but no movement at all toward integrating this feature
> into mainline qemu.
>
> What would be needed to e.g. make the patch series on the mailing list
> acceptable for merge?

The bare minimum is that things need to not break for any
guest x host combination. The RFC patchset from Kirill says
that it doesn't work for all ARM guest code, for instance.
It also needs to fall back cleanly if the backend doesn't support
vector ops, and I'm not sure if the RFC does that. It needs
to implement more than a single test "vector add". It needs
to be reasonably demonstrated that it's actually a win on
real-life code rather than a trivial microbenchmark. The
various concerns listed in the RFC cover letter need to be
discussed and addressed.

This is all certainly doable, but the missing thing is "nobody
is actually doing it", not "we didn't know about this".
An RFC patchset is a sketch of a design, and there's a long
way between that and committable code.

The ACM paper looks like a classic example of a bit of academic
work: maybe they did something interesting, but their intended
end output was a paper, not code, and they never submitted any
patches to us that I'm aware of. (And again, "academic prototype"
and "production code" are often far apart.)

thanks
-- PMM


Closing this because it isn't a bug. (It looks like some of the vector TCG improvements are now in progress and might hit master for 2.12; but in any case having an open bug in the system about this serves no useful purpose.)