[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Expansion Ratio Issue
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] Expansion Ratio Issue |
Date: |
Thu, 29 May 2014 10:04:54 +0100 |
On 29 May 2014 08:58, Chaos Shu <address@hidden> wrote:
> 1. Any benchmarks paying attention to TCG code generate quality
> measured by code expansion ratio? Of course I’ve got some news said that the
> ratio maybe 4 or 5 in X86 to MIPS, that is to say 1 x86 insn to 4 or 5 mips
> insns, Does it mean the industry level or average level? Any official report
> given?
No, we don't in general have any benchmarking of TCG
codegen. I think if we did do benchmarking we'd be interested
in performance benchmarking -- code expansion ratio doesn't
seem like a very interesting thing to measure to me.
> 2. I’ve noticed that once Apple merge from PowerPC to X86, they
> developed the software named Rosetta which is described by apple to be
> successful, is it the same to Qemu? Any internal infos covered?
It's a similar concept, though as I understand it it focused
on doing translation for a single application (like QEMU's
linux-user mode, not like our system emulation mode). I have
no idea about its internal design.
> 3. Assume that we just wanna x86 to arm, so may we can strip out the
> little operations and work on insn to insn such as move in x86 to move in
> arm, insn level translate but not insn-op-insn, I think there must be
> someone have ever made this try, anyone got their news?
Certainly if you started from scratch with the intention of
doing a more specifically targeted design (and in particular
if you wanted to do single-application translation as your core
focus rather than as a bolt-on extension to system emulation)
you could probably get better performance than QEMU. QEMU
generally aims to be a general-purpose project, though.
Personally I would (even if doing only x86-to-ARM) still
include an intermediate representation of some form: the
history of compiler design shows that it has a lot of utility.
> 4. Why Qemu use only one TCG runtime, I found a project named PQEMU
> once try to make TCG running on multicore but it’s out of date and got some
> commercial issues, is there any project trying to make it go?
Not that I currently know of. Truly parallel TCG execution
of multiple guest cores is a hard problem, especially if you
want to produce maintainable solid code that can be included
upstream, rather than just enough of a prototype to demonstrate
proof of concept and run some simple benchmarks for an academic
paper.
thanks
-- PMM