6 ms·

This guy should know better being an iPhone developer. > but it also has the property that method calls in Objective-C are very slow and the more code that you

by sjs 16y ago

This guy should know better being an iPhone developer. > 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 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.)

KirinDave 16y ago
Inline Caching is awesome, and Apple's ObjC runtime has some very cool stuff. 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.
- sjs 16y ago
  I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in practice. However Dalvik being faster today doesn't mean that Obj-C is suddenly not fast enough. And when it's not fast enough you can make it so. 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.
  - KirinDave 16y ago
    I agree that the implicit argument is that ObjC isn't fast enough, and I agree that's an argument that needs some serious evidence before I'll take it seriously. 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.
  - sjs 16y ago
    It seems I misunderstood inline caching. If the call site itself is modified then it can be as fast as the JIT compiler. Interesting.
- loewenskind 16y ago
  Read some of the papers on this site: http://strongtalk.org/ http://strongtalk.org/ What Java has came from Strongtalk (directly), which came from Self which was inspired by what Smalltalk does.
  - KirinDave 16y ago
    Yes, those are good papers and Self was fascinating. Care to go into more concrete detail?
    - loewenskind 16y ago
      My point is simply that inline caching doesn't have an extra jump. It's called inline cache because the caching is writen in place (inline) making calling a method the same as calling a function. The generated function just has a type check at the top to jump back to normal method call scemantics in the case of a miss.
barrkel 16y ago
Java, on the other hand, is able to inline the cached (virtual) method altogether, not just its address.
- bad_user 16y ago
  Those optimizations have a high runtime cost, that's why there's a difference between the client and server profiles in the JVM ... and I'm not sure such optimizations have been enabled in Dalvik.
  - KirinDave 16y ago
    Many of the tricks discussed here come for free with static typed compilation + JIT. All those tedious type annotations are good for at least one thing, it seems. 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.
    - bad_user 16y ago
      > come for free with static typed compilation + JIT 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.

by sjs 16y ago

KirinDave 16y ago

Inline Caching is awesome, and Apple's ObjC runtime has some very cool stuff. 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.

sjs 16y ago
I didn't mean to imply that messages are faster than JIT compiled calls. There's still at least one level of indirection in the optimal case, not sure about in practice. However Dalvik being faster today doesn't mean that Obj-C is suddenly not fast enough. And when it's not fast enough you can make it so. 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.
- KirinDave 16y ago
  I agree that the implicit argument is that ObjC isn't fast enough, and I agree that's an argument that needs some serious evidence before I'll take it seriously. 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.
- sjs 16y ago
  It seems I misunderstood inline caching. If the call site itself is modified then it can be as fast as the JIT compiler. Interesting.
loewenskind 16y ago
Read some of the papers on this site: http://strongtalk.org/ http://strongtalk.org/ What Java has came from Strongtalk (directly), which came from Self which was inspired by what Smalltalk does.
- KirinDave 16y ago
  Yes, those are good papers and Self was fascinating. Care to go into more concrete detail?
  - loewenskind 16y ago
    My point is simply that inline caching doesn't have an extra jump. It's called inline cache because the caching is writen in place (inline) making calling a method the same as calling a function. The generated function just has a type check at the top to jump back to normal method call scemantics in the case of a miss.

barrkel 16y ago

Java, on the other hand, is able to inline the cached (virtual) method altogether, not just its address.

bad_user 16y ago
Those optimizations have a high runtime cost, that's why there's a difference between the client and server profiles in the JVM ... and I'm not sure such optimizations have been enabled in Dalvik.
- KirinDave 16y ago
  Many of the tricks discussed here come for free with static typed compilation + JIT. All those tedious type annotations are good for at least one thing, it seems. 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.
  - bad_user 16y ago
    > come for free with static typed compilation + JIT 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.