On 29 May 2014 08:58, Chaos Shu <chaos.s...@live.com> 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
