> Re: blindfold: "Can you quantify the "vastly slower" Dalvik > interpreter? Is it the factor 5-10 that one typically finds?" > > You're thinking of JIT vs. interpreter. Native code is another > multiplier on top of that.
True, and I may be a bit biased in my preferences, but a good Java JIT nowadays gets fairly close to C compiled to native code, with speed penalties far less than interpreter vs JIT. Gav's results also show this: his Quicksort on the desktop ran only some 20% slower with Sun's JIT vs C. I for one would be perfectly happy with that. I'm aware that a mobile phone JIT will be somewhat less efficient than a JIT on the PC, but in these discussions about factors 5-10 (illustrated again by Gav's Dalvik/JNI graph), I'd say that speed differences of less than 50 percent are mostly insignificant. Although one must indeed be careful about what is "fair" in benchmarking, the overall picture is pretty clear nonetheless and keeps popping up again and again in different contexts with different examples: the Dalvik interpreter is typically 5-10 times slower than both native code and JIT on the same or similar platform, but surely with some exceptions. In my own app it is the missing factor 5 that makes all the difference between real-time performance and unacceptably sluggish non-real-time behavior: real-time is real-time, so I do not need a factor 50 or 500, but just need to calculate one second of 64-channel audio in under one second instead of the current five seconds or so. Java ME devices do that, Android devices don't, for the same source code. That was a setback that I did not anticipate when I started out looking at Android last year (from a background in developing in Java ME / J2ME for mostly Nokia phones and in C for Windows netbooks and MIDs). I understand that bridging the existing performance gap will take time and effort, but with the very spotty Android "roadmap" I cannot plan ahead and decide whether or when it is worthwhile (and in what order) to create a CPU-dependent NDK/JNI based version, a V8-in-Chrome Javascript compiler dependent version (I tried that but the current Android Javascript APIs seem too limited), or wait for a JIT compiler - where the latter is a solidly proven technology for phones featuring Java ME. Regards On Jun 9, 10:56 pm, fadden <[email protected]> wrote: > On Jun 9, 5:40 am, Gavin Aiken <[email protected]> wrote: > > > On Tue, Jun 9, 2009 at 7:55 AM, David Turner <[email protected]> wrote: > > > Why are you using static class variables instead of locals in the Android > > > Quicksort example?They are considerably slower to access. > > Because, I'm very new to this :) Also I read this; > > >http://developer.android.com/guide/practices/design/performance.html#... > > > If I have misinterpreted the meaning I'll go change the source. Anything > > else to make it fairer would be greatly appreciated. > > See "Cache Field Lookups"? I'm not sure that's what digit was > referring to though -- the weird thing I see is in the C code, where > some things that should be locals are stored in global variables. > > The way the code is written can emphasize or de-emphasize the > difference between interpreted code and JITted code. With a literal- > minded compiler like javac, and a straightforward interpreter, the > effects of your coding choices will be very apparent. Throw ProGuard > and a mature JIT into the mix and you can use less-efficient > constructs without paying a price. > > The notion of "fair" doesn't really enter into the way it's coded. > You're not measuring the performance of the VM in general; you're > measuring the performance of your code as it executes on different > platforms. If your code were, say, a popular physics engine, then you > could draw some interesting conclusions about how games based on your > engine would perform, and possibly about integer or floating-point > math-intensive operations in general. You wouldn't be able to say too > much about how a dynamic language would perform though, or how sorting > a massive array would perform. > > So the only place "fairness" counts is in how you characterize the > results. It's perfectly reasonable to write the Java code in the most > inefficient way imaginable and then race it against HotSpot to show > the effects that a mature desktop JIT can have. The trick with any > benchmark run is figuring out what the results really mean. > > Re: blindfold: "Can you quantify the "vastly slower" Dalvik > interpreter? Is it the factor 5-10 that one typically finds?" > > You're thinking of JIT vs. interpreter. Native code is another > multiplier on top of that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
