permissions: 0.170
other: 0.101
device: 0.083
performance: 0.077
socket: 0.074
graphic: 0.073
semantic: 0.071
files: 0.065
debug: 0.064
boot: 0.060
PID: 0.058
network: 0.040
vnc: 0.037
KVM: 0.027
performance: 0.584
files: 0.073
debug: 0.056
other: 0.052
network: 0.050
PID: 0.043
boot: 0.030
semantic: 0.030
vnc: 0.021
socket: 0.017
device: 0.016
permissions: 0.012
KVM: 0.009
graphic: 0.007

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