add 18th iteration of classifier

1 files changed, 43 insertions, 0 deletions

diff --git a/results/classifier/118/performance/2906 b/results/classifier/118/performance/2906
new file mode 100644
index 00000000..3757a298
--- /dev/null
+++ b/results/classifier/118/performance/2906
@@ -0,0 +1,43 @@
+performance: 0.982
+x86: 0.975
+architecture: 0.972
+graphic: 0.802
+mistranslation: 0.802
+device: 0.801
+arm: 0.636
+semantic: 0.617
+permissions: 0.351
+files: 0.332
+debug: 0.323
+register: 0.309
+boot: 0.307
+network: 0.289
+risc-v: 0.279
+PID: 0.278
+socket: 0.272
+hypervisor: 0.252
+user-level: 0.242
+vnc: 0.236
+i386: 0.225
+VMM: 0.170
+ppc: 0.154
+kernel: 0.140
+TCG: 0.124
+virtual: 0.089
+peripherals: 0.086
+KVM: 0.065
+assembly: 0.048
+
+x86 (32-bit) multicore very slow, but x86-64 is fast (on macOS arm64 host)
+Description of problem:
+More cores doesn't slow down a x86-32 guest on an x86-64 host, nor does it slow down an x86-64 guest on an arm64 host. However, adding extra cores massively slows down an x86-32 guest on an arm64 host.
+Steps to reproduce:
+1. Run 32-bit guest or 32-bit installer
+2.
+3.
+
+I have replicated this over several OSes using homebrew qemu, source-built qemu and UTM. This is not to be confused with a different bug in UTM that caused its version of QEMU to be slow.
+
+This also seems to apply to 32-bit processes in an x86-64 guest.
+Additional information:
+https://github.com/utmapp/UTM/issues/5468