From: Paolo Bonzini <pbonzini@redhat.com>
To: Lior Vernia <liorvern@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Andreas Färber" <afaerber@suse.de>,
qemu-devel@nongnu.org, 陳韋任 <chenwj@iis.sinica.edu.tw>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
Date: Mon, 27 May 2013 08:59:50 +0200 [thread overview]
Message-ID: <51A30466.6020703@redhat.com> (raw)
In-Reply-To: <CALBwSP1s+U57w_qgR66qwqFhXorJjkcAjBMHpYafu=Ne7KoBgg@mail.gmail.com>
Il 26/05/2013 18:35, Lior Vernia ha scritto:
> What about no to the first bullet but yes to the second (just x86 on
> ARM)? Any room for significant improvement in that case, starting from
> the foundations of QEMU?
You could write a target-specific translator, yes. But first of all I
would answer whether you're using 32- or 64-bit, and run some profiling
to see what is the hotspot in your case.
I know that in some scenarios helpers for SSE take a considerable amount
of time (5-10%). You could look at adding SIMD data types to TCG, and
map them to Neon operations or even to fully-unrolled loops.
As other works, ahead-of-time translation can also do a lot more
optimizations, including very aggressive dead-code elimination. For
example, again considering SSE, something like
pcmpeqw %xmm0, %xmm1
pmovmskb %xmm1, %eax
test %eax, %eax
jz ...
will be translated to a slow sequence in QEMU due to the expensive
pmovmskb. A custom code generator can observe that %eax is dead and use
a better translation of this idiom.
Also, floating-point emulation is always done in software in QEMU due to
different representations (and due to the 80-bit floating-point
registers mostly used by 32-bit x86). This is going to be slow no
matter what.
Paolo
prev parent reply other threads:[~2013-05-27 7:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 19:24 [Qemu-devel] Potential to accelerate QEMU for specific architectures Lior Vernia
2013-05-25 17:48 ` Blue Swirl
2013-05-25 19:06 ` Andreas Färber
2013-05-25 21:16 ` Paolo Bonzini
2013-05-26 5:40 ` Lior Vernia
2013-05-26 9:00 ` Andreas Färber
2013-05-26 16:03 ` Lior Vernia
2013-05-26 9:26 ` Peter Maydell
2013-05-26 9:58 ` Gleb Natapov
2013-05-26 10:11 ` Peter Maydell
2013-05-26 16:35 ` Lior Vernia
2013-05-27 6:59 ` Paolo Bonzini [this message]
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=51A30466.6020703@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=chenwj@iis.sinica.edu.tw \
--cc=liorvern@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.