On Thu, Jul 30, 2015 at 10:55 AM, Aurelien Jarno <aurel...@aurel32.net> wrote: > On 2015-07-30 10:16, Dennis Luehring wrote: >> Am 30.07.2015 um 09:52 schrieb Aurelien Jarno: >> >On 2015-07-30 05:52, Dennis Luehring wrote: >> >> Am 29.07.2015 um 17:01 schrieb Aurelien Jarno: >> >> >The point is that emulation has a cost, and it's quite difficult to >> >> >to lower it and thus improve the emulation speed. >> >> >> >> so its just not strange for you to see an 1/100...200 of the native x64 >> >> speed under qemu/SPARC64 >> >> i hoped that someone will jump up an shout "its impossible - it needs to >> >> be >> >> a bug" ...sadly not >> > >> >Overall the ratio is more around 10, but in some specific cases where >> >the TB cache is inefficient and TB can't be linked or with an >> >inefficient MMU, a ratio of 100 is possible. >> >> >> sysbench (0.4.12) --num-threads=1 --test=cpu --cpu-max-prime=2000 run >> Host x64 : 1.3580s >> Qemu SPARC64: 184.2532s >> >> sysbench shows nearly ration of 200 > > Note that when you say SPARC64 here, it's actually only the kernel, you > are using a 32-bit userland. And that makes a difference. Here are my > tests here: > > host (x86-64) 0.8976s > sparc32 guest (sparc64 kernel) 99.6116s > sparc64 guest (sparc64 kernel) 4.4908s
Wow. That's quite a difference. What have you used as a sparc64 guest? Are there any ready-to-use distributions, or have you built it from scratch? > So it looks like the 32-bit code is not QEMU friendly. I haven't looked > at it yet, but I guess it might be due to dynamic jumps, so that TB > can't be chained. > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
