There are so much misinformation in this thread. Let's try to clarify: The *main* bottleneck for slow performance in the emulator is OpenGLES emulation, which is currently performed in software, moreover in emulated ARM instructions. All platform releases are emulated by the same virtual CPU, the differences in performance come from the following facts:
- Gingerbread switched to use 32-bit surfaces by default for all activities. Even if the emulated framebuffer is still 16-bit, that's about twice the cost per pixel for each operation, hence why it is slower than Froyo at comparable resolutions. Apart from that, the platforms are nearly identical (well, the JIT in Gingerbread is much better than in Froyo). - Honeycomb uses OpenGL ES much more aggressively than Gingerbread. As a consequence, there are a lot more operations involved per pixel (due to all the fancy effects), which results in the current lack of performance. As demonstrated by Xav at Google I/O, we're working on a solution to render all GLES operations on the host GPU, which will significantly speed things up. No ETA, it will be released when it's ready (hint: it's not). Now, assuming the GLES problem is handled, the second reason why the emulator is slow is the software MMU. In other words, each memory load or store operation in the guest must involve a lengthy translation (from guest virtual address to guest physical address to host address within the emulator process). This translation depends on the state of the emulated virtual ARM CPU and cannot be done easily. To speed things up, a small 256-pages cache is used but this results, in the best case, in a series of 20-something host instructions + several memory accesses to implement a single load or store (when you hit the cache, things are _much_ worse in case of a miss). Finally, there is the issue of translating each ARM instruction into a series of host x86 instructions. This of course has an impact, but most arithmetic operations can be translated into something that is hardly 2x or 3x slower than the real thing. Compared to the cost of virtual memory access, this is minimal. On Tue, May 31, 2011 at 9:30 PM, jtoolsdev <[email protected]> wrote: > Ah, the emulator isn't running ARM code just the Dalvik engine. The > problem has been addressed elsewhere by developer supprot that it is > not possible to build an emulator so far that can take advantage of > the graphics acceleration on your PC. > > On May 31, 12:25 pm, String <[email protected]> wrote: > > The bottleneck is the emulation of ARM on x86, compounded by the number > of pixels it needs to push around to emulate modern devices. There is no PC > on which it has usable performance. > > > > String > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
