1 files changed, 104 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/1594069 b/results/classifier/118/permissions/1594069
new file mode 100644
index 00000000..258458c3
--- /dev/null
+++ b/results/classifier/118/permissions/1594069
@@ -0,0 +1,104 @@
+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.)
+
+