[Qemu-devel] 答复: Expansion Ratio Issue

[Chaos Shu]

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.

[Chaos] Assuming that we just care about running x86 application on arm, in 
general way we translate x86 insn to operations then to arm insns, but that 
means we need more cycles in arm to finish issuing the insns if the code 
expansion ratio is high.

I've investigated some industry methods such as registers map(x86 registers 
maps to arm registers directly but not op on register memory table), actually 
the improvement is limited

And another idea such insn-insn directly, according the runtime statistics, 
mostly we use 20% insn such as br move load, I mean is that possible to map 
those 20% insns directly from x86 to arm and make the left 80% right, but this 
is just original and more important maybe impossible to practice idea, is there 
any research about this on the way? How do you think about this?

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

[Chaos] I think ARM should provide a runtime library help the customers to 
merge from x86 more smoothly even performance loss, So does arm really get 
that? 

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

[Chaos] Case be compiled, all syntax information has been stripped out, all we 
get is op_reg_reg different from JVM, we only dance with registers and insn 
without anything, that's the problem.

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

[Chaos] After all, what's current status of industry product making x86 
application running on arm? Is still dark night in middle age and I have to 
make big effort to make Qemu to be so? 

Anyway, any infos about that issue is welcome, thanks very much.

Thanks
Chaos