On Thu, Jun 12, 2008 at 5:22 PM, David Given <[EMAIL PROTECTED]> wrote:
> Certainly, the emulator's slow to the point of being only marginly > usable on my home machine --- 3.2GHz Celeron D --- and sluggish but > better on my work machine --- a 2.4GHz Core Duo. The emulator's speed > isn't representative of very much, of course. > yes, the emulator is slow; mainly because: - emulating a full ARM MMU in software is very demanding, no matter how you do it - the emulator's JIT translates original ARM code in native code that can be easily 20x larger. and CPUs with small instruction caches (e.g. Celerons) really don't like that the emulator doesn't have graphics hardware acceleration, writing to its video framebuffer is even comparatively slower than on a real hardware (each write is an i/o page fault which is considerably slower than an emulated RAM write) so its graphics performance is nothing to scream about :-) we plan to emulate OpenGL ES someday, but this is not a priority, and it's always good to know that the system runs acceptably on low-end hardware. > , for example, and that hits performance > right where the user will notice it: application startup. Given that > JITs these days are known technology, not particularly hard to do, and > give such staggering performance improvements I'd be really surprised if > one wasn't on the roadmap *somewhere*, and I'd expect it to be sooner > rather than later. > A Jit uses more CPU and more memory than an interpreter, sometimes by a significant margin. Also JIT-ed code doesn't perform as well on a CPU like the ARM that has a *tiny* instruction cache (16 kB, with round-robin, a.k.a. the worst-performing cache replacement policy) what I mean is that you should probably expect a modest performance advantage in the general case when using a JIT at the cost of reduced battery life and increased memory pressure. other techniques like pre-compilation might be useful too and not tax the runtime system that much. also a JIT doesn't make soft-floating point operations magically faster, or speed up your framebuffer, etc... Android's process separation also means that sharing the JIT-ed code between VMs is very hard or impossible to do. we're still open to experimentation and measurements regarding Dalvik's performance tuning, but what we really care right now is having an interpreter-based system that runs well for our needs. > > -- > David Given > [EMAIL PROTECTED] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Internals" group. To post to this group, send email to android-internals@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-internals?hl=en -~----------~----~----~----~------~----~------~--~---
