As Dianne mentioned and others have before, the bottleneck is the dynamic translation of ARM opcodes to x86 opcodes. Other VM's like Vmware emulate hardware, but they are still executing code natively albeit with some hypervisor that itself has direct hooks within modern processors. The WebOS and WP7 and iOS emulators are all running builds compiled natively for x86 so they are fast. The Android emulator does not, though I don't see why it couldn't be. The emulator is unusable, I only use real devices except for UI assessment on smaller screens, though I use that less and less as the UI builder/previewer becomes more feature rich.
Jonathan On Jan 28, 11:19 pm, Marcin Orlowski <webnet.andr...@gmail.com> wrote: > > All I was trying to say that emulating of 1GHz of any non native code > > at the instruction level will be slow on a 2Ghz host. I'd bet if you > > tried to run a PacMan 8-bit CPU at 1GHz, it wouldn't emulate at full > > speed or even come close. > > 8-bit or not is not directly related to possible emulation speed. And > this is just type of architecture which is not > the only factor that influences the whole process (and yes, you can > run 8-bit pacman full speed on far slower devices - i.e. Spectrum > emulator on Palm phone (which is 300MHz). I believe in case of Android > the bottlenecks is not just different architecture but also a GPU > support (or lack of h/w support of such) which hits performance badly. > In general I believe it would help if Google could just spend a few > bucks and simply hire bunch of folks from "emulators scene". -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
