Re: [Qemu-devel] Expansion Ratio Issue

[Alex Bennée]

Peter Maydell <address@hidden> writes:

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

Not to mention that raw instruction counts are probably misleading
compared to the effect you can get from instruction ordering and cache
behaviour.

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

Rosetta was based on QuickTransit from Transitive (since bought by IBM).
It's broadly analogous to QEMU's linux-user mode emulation although it
attempted a more complete separation between translated and native
processes. In the QEMU world all the processes can "see" each other
which can cause issues if they are expecting certain endianess on
wire-formats.

The biggest difference internally is the translator was IR based, it
built up a DAG of operations which it manipulated/optimised much like a
compiler does before generating the final target code. QEMU instead
generates a simple set of TCG ops for each instruction which after a
little optimisation spits out a set of target instructions.

QuickTransit was certainly pretty high performance compared what else
was out there at the time. From memory it implemented a number of other
features to get this speed:

 * Group blocks - hot paths of basic blocks would be regenerated as a
   single block.
 * Block cache - it would cache previous translations to avoid heavy
   start-up cost
 * Native binding - it could optionally detect special code paths in
   translated code and replace them with a direct binding to a native
   code (e.g. call the native memcpy rather than translate the guest
   version).

>
>> 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?

In the linux-user case you do utilise multiple core with multiple
instances of QEMU running (which is handy for package building type
tasks). However fixing QEMU for fully multi-threaded translation is a
hard task. You may even find you don't get that much from it as ideally
you should spend more time running translated code than doing the
transaltion.

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

-- 
Alex Bennée