[Top][All Lists]

[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

-- PMM

reply via email to

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