[Top][All Lists]

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

Re: [Qemu-devel] Reporting Heisenbugs in qemu

From: Rob Landley
Subject: Re: [Qemu-devel] Reporting Heisenbugs in qemu
Date: Wed, 08 May 2013 19:28:27 -0500

On 05/08/2013 04:45:45 AM, Torbjorn Granlund wrote:
Paolo Bonzini <address@hidden> 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:


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...)


reply via email to

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