[Locke1689]

I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the performance target.

P.S. If you think QEMU is slow, don't even think about Bochs.

[jamesg]

QEMU is a truly awesome piece of code. Everything Fabrice Bellard does is incredible.

You could well be right that they're not using it correctly -- that sounds entirely plausible. I guess my point was more that, whatever the cause, the net effect of it is that the Apple Simulator is unrealistically fast, and the Android Emulator is unrealistically slow. Neither really encourage great development if you rely on them.

[Locke1689]

Agreed -- I just wanted to defend QEMU (and my own work, by extension) for a moment.

Also, code can always be made to go slower so I'm not sure if "unrealistically fast" is as bad a "unrealistically slow."

[kbutler]

It's actually much easier to "virtualize another OS" than to virtualize a hardware platform (and associated OS).

If you are running guest code that matches your host architecture, QEMU can run the code natively. If you are running foreign code (e.g., ARM on an Intel host), it has to dynamically recompile the code, which will hurt performance.

kb

[Locke1689]

Actually, my research was simulating a different hardware architecture and the patch I have is for hardware-assisted virtualization under arbitrary hardware architectures. It does have to recompile the code, but the TCG does a pretty good job of that. The virtualization target can do a lot better by keeping TCG in mind while structuring its binary execution, which may be one thing that they don't try to do in Android.