[android-developers] Re: Android emulator bottleneck
The docs are a little vague about any ARM emulation. It says the SDK contains ARM machine code for the Android Linux kernel. Would it use that on Windows? And then it wouldn't be the first time the docs are left vague as we all know. Seems to me if you are running Java byte code then all you need is a layer for that but maybe not. I don't have to time to play systems engineer on top of application developer. That will make you a jack of all trades and master of none in today's tech world. :D But I do know that I read a response on this group from support that the problem had to do with not being able to use the graphics card acceleration on the PCs. Someone will probably figure that one out though. On May 31, 1:13 pm, Chris Stratton cs07...@gmail.com wrote: On Tuesday, May 31, 2011 3:30:39 PM UTC-4, jtoolsdev wrote: Ah, the emulator isn't running ARM code just the Dalvik engine. Really? There's an x86 build of honeycomb? And an x86 toolchain in the NDK? I don't believe that is the case... unfortunately. -- 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
[android-developers] Re: Android emulator bottleneck
Yes there is. Intel has honeycomb running on their IA (Intel Architecture). But it's all in early phases. But Google TV runs on x68 and Google TV will upgraded to Honeycomb (3.1) this year. -- 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
[android-developers] Re: Android emulator bottleneck
From discussions with the Google Engineers, the emulator emulates the *entire *device on the lowest levels, not just the DalvikVM. It emulates the ARM processor and the code that runs on it and a bunch of the in and output devices (keyboard, touchscreen in some form, screen, GPS, etc). You can run NDK code (c/c++) on your emulator. They told us at Google IO (and other conferences) that the biggest performance bottleneck is the rendering of (large) screens. They are working hard in having the screen rendered on the PC's hardware (GPU) instead of doing it all in software (rendering the screen pixel by pixel). Some early demo was shown at Google IO and it looks very promising. -- 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
[android-developers] Re: Android emulator bottleneck
I have a 3.3ghz quad core with 4 gb ram that runs 2.3.3 on the emulator fine at WQVGA432. Same computer fails miserably to run 3.0 at WXGA. Runs fine, that is, except when it decides to randomly crash when clicking anywhere on the skin, and then failing to clean up after itself and usually keeping a zombie emulator process running. So I guess it depends. -- 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
[android-developers] Re: Android emulator bottleneck
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 sterling.ud...@googlemail.com 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 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
[android-developers] Re: Android emulator bottleneck
On Tuesday, May 31, 2011 3:30:39 PM UTC-4, jtoolsdev wrote: Ah, the emulator isn't running ARM code just the Dalvik engine. Really? There's an x86 build of honeycomb? And an x86 toolchain in the NDK? I don't believe that is the case... unfortunately. -- 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
Re: [android-developers] Re: Android emulator bottleneck
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 brianjto...@gmail.com 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 sterling.ud...@googlemail.com 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 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 -- 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
Re: [android-developers] Re: Android emulator bottleneck
Okay, I stand corrected. But you'll notice that there was no attempt to correct this part: There is no PC on which it has usable performance. I don't dispute that Android emulation is a hard problem. The unfortunate fact remains that Honeycomb development simply isn't possible without a hardware device. String -- 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
