qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to spe


From: Aurelien Jarno
Subject: Re: [Qemu-devel] Debian 7.8.0 SPARC64 on qemu - anything i can do to speedup the emulation?
Date: Thu, 30 Jul 2015 10:55:00 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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

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
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]