Android Dalvik VM performance is a threat to the iPhone
javarants.com
javarants.com
> but it also has the property that method calls in Objective-C are very slow and the more code that you write in Objective-C instead of in C/C++ the slower your codebase becomes.
Obj-C is not "very slow". While it's very dynamic most code is fairly static. You setup classes with methods, instantiate objects of those classes, and send them messages. Methods are cached after the first lookup and unless you are doing very dynamic things the subsequent messages find the corresponding method rather quickly. This is old stuff and you'll find it in Smalltalk, Self, and since Rubinius is based on the blue book I bet even Ruby. It's called inline caching[1]. If you need performance in a tight loop or something you drop into C, and this is encouraged. If your Obj-C code is too slow then you optimize it. In most cases this is entirely unnecessary or has been done for you at a lower level.
Without some numbers you can't expect anyone to take these claims seriously. Obj-C has been around for 20+ years. That's plenty of time for optimization and even micro-optimization, by some of the best in the industry.
[1] http://en.wikipedia.org/wiki/Inline_caching
It's nice to see Dalvik perform so well, just spare us the BS speculation about performance.
(I'm also not convinced that Android development is "just Java" considering how vastly different it is from more traditional Java development, but I'll leave that one alone for now.)
Perhaps I misunderstand what inline caching is doing, but how would that end up being faster than direct invocation? The java compiler can remove all indirection entirely, without violating any language semantics. As much as specifying all those types is tedious, it does give the compiler the capacity to do that.
It's not as nice as it just being done automatically, the JIT is still preferable (imo). But when it comes down to Java vs. Obj-C, even with all the verbosity, I prefer Obj-C. Even at the price of typing stringByReplacingOccurrencesOfString:withString: and some (rare) manual optimization.
But it is something to consider. Apple really hamstrung the freedom that having a c-friendly programming environment gave them with their new no-VMs policy. We were seeing great uses of things like lua and the door was open for LLVM, which really could have offered absurdly cool possibilities.
As it stands, we'll just have to hope all this clang magic makes it into the next iPhone dev kit release. A better static compiler will help a lot.
What Java has came from Strongtalk (directly), which came from Self which was inspired by what Smalltalk does.
Care to go into more concrete detail?
I'd think the #1 thing balancing this right now is the overhead of the GC. No matter how good a GC we get, it's still going to be more costly than well-written direct memory management except in degenerate cases.
NO. Static typing doesn't help when speaking about inline caches for virtual calls (most method calls in a typical Java app) ... it only helps on the initial method lookup because you're dealing with a vtable instead of a hash (that's because at least you know the interface at compile-time).
But to do code-inlining and other such optimizations, the Hotspot JVM only compiles bytecode that has been profiled. That's because jitting itself is an expensive operation and you can't just redo it after you've inferred the conditions of a potential call-site cache, being more efficient to just first interpret that code until you have enough data.
Thus the long warmup time. But what works in a desktop/server environment doesn't necessarily work on a mobile phone with much less constrained resources ... and unfortunately Moore's law in the mobile world goes to increased battery life instead of increased processing power / bigger or faster RAM.
I still think Java was a poor language choice for Dalvik precisely because methods in Java are implicitly virtual and because you can't have custom stack-allocated values. A language like C# would've been more suitable ... but since its their VM, maybe they'll provide an efficient alternative.
Are you sure? I thought in certain conditions Java could dispense with the vtable lookup even in interpreted land. Not that it matters nearly so much there.
> But to do code-inlining and other such optimizations, the Hotspot JVM only compiles bytecode that has been profiled. That's because jitting itself is an expensive operation and you can't just redo it after you've inferred the conditions of a potential call-site cache, being more efficient to just first interpret that code until you have enough data.
So you're saying the Dalvik JIT does not do this? The reason I said "static typed compilation + JIT" was because, in my reading of the literature anyways, at jit time it could dispense with the vtable lookup if it's seen a stable type signature.
> I still think Java was a poor language choice for Dalvik precisely because methods in Java are implicitly virtual and because you can't have custom stack-allocated values. A language like C# would've been more suitable ... but since its their VM, maybe they'll provide an efficient alternative.
Please no. C# has, unsurprisingly, evolved into an absolute soup of a language. It's a crud-infested nightmare. The only thing saving me from absolute insanity these days is the slow migration to F#.
But really, since our comparison is to Objective C, where all calls are method dispatch which is a slightly more expensive than java calls, I don't think we're losing much. At best, Java is slightly faster. At worst, Java uses the same technique (or is interpreted, but again it doesn't seem to be losing that badly in this mode).
Not for calls to virtual methods, especially those call done through an interface ... you can't infer the right method to call at compile time when you don't know the object's real type. And in Java you can also load new classes that implement a certain interface at runtime ... and this also makes optimizations more difficult.
Now of course ... for calls to static functions or for calls on methods marked as "final" Java can and does dispense of the vtable lookup.
Unfortunately in Java methods are implicitly virtual, as you have to explicitly mark them as being final (for performance, although as far as language design for the stuff I do, I like it).
> Please no. C# has, unsurprisingly, evolved into an absolute soup of a language
I meant ... just as high level as Java, but with lower level capabilities here and there (where it matters). I don't think having your custom stack-allocated values or having pointers in "unsafe" portions of code (which really is a lot safer than doing JNI) is that big of a deal, and can help a lot in constrained environments.
Yes. I think we've actually been arguing the same point and just stating it differently. My original argument was that the Java way is actually always as fast and potentially faster than the ObjC way. Everything that works for ObjC works for Java, but java has semantics that allow for further optimization without breaking the required behavior of message passing.
> I don't think having your custom stack-allocated values or having pointers in "unsafe" portions of code (which really is a lot safer than doing JNI) is that big of a deal, and can help a lot in constrained environments.
I wonder. Most GCs are doing allocation that is only an instruction or three (I don't know what it'd look like on ARM) more overhead than incrementing the stack pointer. The CLR is somewhat famous for this. It is a bit of a bummer that you lose prescriptive-layout for structure types in java, though.
But that's not the point ... stack-allocated values help with mathematics, like boolean comparisons, matrix multiplication or just plain arithmetic, because otherwise you have to box/unbox those values. Software that relies on that (graphics / animations come to my mind, but not only) ... can take a big performance hit.
And even if the GC is very efficient, you can still strangle it with many small objects, and sometimes those objects aren't deallocated fast enough. Stack allocation/deallocation is much more predictable for lots of small objects.
But I think you already addressed this point.
Even if a vendor uses custom skin, it does not mean that applications are inconsistent.
You have to actively work around to look and behave out of place.
But it doesn't seem to be the case. Some apps have half their settings in a "main menu" which is activated by touch and hang the rest of the "menu" button. Some apps put everything in "menu". Others have multiple "menu"s depending on where you are -- K-9 mail is a good example of this, where "menu" is context-sensitive, and preferences (for example) are distributed across three different displays. This is only intuitive once you grok the app layout. Others do horrible things such as putting menu items labelled "more" in their menus.
With the "back" button, there is no guarantee that pressing "back" will take you back. Sometimes it takes you to what you were previous doing, browser-style. Sometimes it takes you to an application's main screen. Sometimes it takes you to the home screen. It depends (I guess) on how the app author has organised the Activities in her app.
Really, the only consistent button on Android phones is the iPhone-like "Home" button.
You might be right, though, and I may just get by despite the UI problems, but that's surprising if so.
It's really sad that such a disclaimer is needed.
http://www.iphonedownloadblog.com/2010/05/07/android-running...
It'd be interesting, but I wouldn't make any large wagers just yet.
Besides, most of the juice you're going to get is going to be in your JIT.