From: Paolo Bonzini <pbonzini@redhat.com>
To: Torbjorn Granlund <tg@gmplib.org>
Cc: Artyom Tarasenko <atar4qemu@gmail.com>,
Aurelien Jarno <aurelien@aurel32.net>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Reporting Heisenbugs in qemu
Date: Wed, 8 May 2013 06:18:40 -0400 (EDT) [thread overview]
Message-ID: <127138633.7673707.1368008320404.JavaMail.root@redhat.com> (raw)
In-Reply-To: <86fvxxoldi.fsf@shell.gmplib.org>
> 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?
No idea. :) Of all the architectures you listed, MIPS is really the one
that I have no inkling of...
> If register windows shortage is a problem, it should be easy to pretend
> to have lots of them, right?
That can help to avoid trapping to the kernel. But you still have to
spill the whole window to the stack on every call to a non-leaf function,
which can be expensive even if you do it in the translated code.
Paolo
next prev parent reply other threads:[~2013-05-08 10:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 11:38 [Qemu-devel] Reporting Heisenbugs in qemu Torbjorn Granlund
2013-05-07 13:25 ` Mark Cave-Ayland
2013-05-07 15:50 ` Aurelien Jarno
2013-05-07 16:18 ` Torbjorn Granlund
2013-05-07 21:29 ` Artyom Tarasenko
2013-05-07 21:43 ` Torbjorn Granlund
2013-05-07 21:53 ` Artyom Tarasenko
2013-05-07 23:06 ` Torbjorn Granlund
2013-05-07 22:57 ` Aurelien Jarno
2013-05-08 7:25 ` Paolo Bonzini
2013-05-08 9:45 ` Torbjorn Granlund
2013-05-08 10:18 ` Paolo Bonzini [this message]
2013-05-09 18:15 ` Blue Swirl
2013-05-08 10:35 ` Aurelien Jarno
2013-05-09 0:28 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=127138633.7673707.1368008320404.JavaMail.root@redhat.com \
--to=pbonzini@redhat.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=qemu-devel@nongnu.org \
--cc=tg@gmplib.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.