Re: [Qemu-devel] Reporting Heisenbugs in qemu

[Rob Landley <rob@landley.net>]

On 05/08/2013 04:45:45 AM, Torbjorn Granlund wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>   I guess that's the register windows.  There's only so much you can  
> do to
>   optimize them, and heavily recursive workloads (like Perl, or the  
> RTL
>   half of GCC) pay a hefty price.
> 
> Two qemu targets stand out for slowness, sparc (32 and 64) and mips  
> (64,
> don't know about 32).
> 
> x86 (32 and 64), arm, and ppc run with a slowdown of < 30 for my bogus
> benchmark of GMP configure+make.
> 
> With FreeBSD x86_64 I see a slowdown of just 13.  (My reference system
> runs FreeBSD, so running FreeBSD under qemu is only far.)
> 
> My claimed slowdown factors are affected by kernel, libraries, and
> unfortunately very much by gcc speed, which vary with target.
> 
> If the sparc emulation speed is due to register windows, then why does
> mips seem just as slow?
> 
> If register windows shortage is a problem, it should be easy to  
> pretend
> to have lots of them, right?

sh4 is pretty slow too. Unfortunately:

   http://landley.net/aboriginal/bin/system-image-sh4.tar.bz2

Only has 64 megs of memory in the emulated board. (Enough to build  
hello world, not enough to build most packages.) I have a vague todo  
item to add a command line thing to qemu to plug a physical memory  
address range into an aribtrary address and then tell linux  
discontigmem "add memory range HERE" on the command line. That way I  
wouldn't have to hack up each board emulation to get more memory...)

Rob