One of the peculiarities of Apple is that they have set themselves down a path where every Apple developer needs to learn Objective-C (and C/C++) to build applications for their platform. The biggest characteristic of Objective-C vs Java is dynamic dispatch. At runtime Objective-C can send arbitrary messages to objects and they may or may not respond to them. This has the nice property that you can write code that is very dynamic and loosely bound 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. Up until Android 2.2 (Froyo) the JVM (really a Dalvik JVM for licensing reasons) on the Android platform was playing with one hand tied behind its back. Different from desktop/server Java, the JVM was still an interpreter, like the original JVM back in the Java 1.0 days. It was very efficient interpreter but an interpreter none-the-less and was not creating native code from the Dalvik bytecodes that it uses. As of Android 2.2 they have added a JIT, a just-in-time compiler, to the stack that translates the Dalvik bytecode into much more efficient machine code much like a C/C++ compiler. You can see the results of this in the benchmarks of Froyo which show a 2-5x improvement. As they add more and more JIT and GC features that have appeared in HotSpot, JRockit, etc, you will likely see even more improvements over time — without having to change or recompile the 3rd party developed software.
This wouldn’t be that big a deal if Android software wasn’t already approaching the speed of the Apple iPhone even when running its applications through the interpreter (see the HTC EVO 4G running 2.1). This is likely going to mean that 3rd party developer applications created for Android, running on the same hardware, is going to be faster than the same code written against the Objective-C libraries that Apple provides for the iPhone. You’ll be able to get more done, have smoother user interfaces and all around build more powerful applications easier. A better experience for the user and the developer on Android is a bad thing for Apple.
The final issue that Apple has is that far more people know and need to know Java than Objective-C. Except for their platform, there is no need to ever learn it. The tool chain is much more robust, information is much easier to come by, garbage collection is available, and there are thousands more libraries written in Java than Objective-C and far more portable libraries than are written for C/C++. You might argue that you can always drop down to C/C++ code to make up for the lost performance of using Objective-C (at a significant cost development-wise). You can do that, except places where you need to make a call into Apple’s Objective-C runtime libraries or where you want to write callbacks from those libraries. Those are mostly Objective-C libraries and use the dynamic dispatch mechanism which I showed in 2004 was very much slower than Java. I’d really love to see the whole computer language shootout written with Objective-C calling conventions just to show how much slower it is at that level.
Obviously performance is not the only consideration, but it is a big one. Android has other issues like a fragmented operating system base, hardware feature base and a more complicated user experience. All those things will conspire to hold it back but I think we can see the writing on the wall that Android is going to dominate iPhone market-share wise which will eventually make it a more attractive platform business-wise.
Update: Just so people don’t get the wrong idea, I am a rabid iPhone user and develop for the iPhone first. This blog entry is to call out a threat that Apple should take seriously.
Update 2: Alright, you win. Don’t worry about competing with Google & Android on performance. It probably doesn’t matter that much for the user experience. Especially don’t fix obj_msgSend() with a JIT/LLVM, that would be crazy.
@
> I’d really love to see the whole computer language shootout written with Objective-C calling conventions just to show how much slower it is at that level.
Demonstrate that calls/callbacks to Apple's Objective-C libraries actually are the bottleneck in real apps.
Deliberately writing slow Objective-C implementations for benchmarks game programs would demonstrate nothing relevant.
Back in the day – http://shootout.alioth.debian.org/debian/compar...
Is this based on comparable processor speeds?
Pingback: Stefan Arentz − How fast are Objective-C method invocations? (Spoiler: Very fast)
Double-spacing after a period/full-stop? Was this written in 1980 on a type-writer or are you planning on a mono-spaced font being put in the CSS. No need for it – very distracting.
It does actually. It means that you can't use the productive language, Objective-C, for those parts of your program where speed matters and you have to fallback to native code. Android programs can all written in Java at near native speeds. The benchmarks you cite from back in the day compare the Objective-C compiler compiling the C benchmarks, not Objective-C code.
I'll take that under advisement.
The benchmarks that I have done are on the same machine. Unfortunately for Apple, the processor speeds of the high end Android devices will always be faster because of the difference in release rate of the two systems. One phone a year vs at least a half dozen all leap frogging one another.
> Garbage collection for Objective-C is not yet available on iPhone, only for real Mac OS X
Oh thanks God it’s NOT available on iPhone and I home will never be available.
Seriously? Seriously?!
I didn't even notice until I saw your comment. Maybe you should practice reading instead of masturbating so much…
Thought you might find this interesting since you mentioned Android fragmentation in your post( link at bottom). A lot of people (myself included) that shared your thoughts on the current state of android has changed their minds after reading it and I was curious as to your take on it.
http://www.engadget.com/2010/05/22/entelligence...
Pingback: Android Dalvik VM performance is a threat to the iPhone
When in the history of computing has the performance of a particular language ever had any impact on how popular or successful its associated computing platform was?
In contrast, when has a freeware, hobbyist operating system ever become more popular or successful than a commercially viable one with a functional business model?
I had to write in – I hate double spacing after periods too. It's always made writing come across as snooty to me.
Unfortunately for reality, the vast majority of the userbase will always be running on something other than the fastest available processor because users don't buy a new phone every time a new model is released so unless you are doing some HTPC or video encoding work on your phone the fact that there is a processor out there that is slightly faster is irrelevant to a typical user.
One makes me a lot more money than the other. End of discussion.
One makes me a lot more money than the other. End of discussion.
Your argument is that Apple will be at a severe competitive disadvantage due to the performance penalties of Objective-C compared to the new JIT compiler. Since the JIT compiler has not yet been released and Android is operating with severe performance penalties compared to currently shipping iPhones (per your own metrics, 2-5x slower than with the JIT compiler) how has Android been able to grow so quickly? If I follow your argument than Android should be getting destroyed in the market right now because of its currently huge performance disadvantage in current models.
Let's posit a different argument — small performance disadvantages in method calling ABI are completely irrelevant compared to the actual performance, features, and user experience of the platform in consumer electronics devices (like smartphones).
Your argument is that Apple will be at a severe competitive disadvantage due to the performance penalties of Objective-C compared to the new JIT compiler. Since the JIT compiler has not yet been released and Android is operating with severe performance penalties compared to currently shipping iPhones (per your own metrics, 2-5x slower than with the JIT compiler) how has Android been able to grow so quickly? If I follow your argument than Android should be getting destroyed in the market right now because of its currently huge performance disadvantage in current models.
Let's posit a different argument — small performance disadvantages in method calling ABI are completely irrelevant compared to the actual performance, features, and user experience of the platform in consumer electronics devices (like smartphones).
Your argument is that Apple will be at a severe competitive disadvantage due to the performance penalties of Objective-C compared to the new JIT compiler. Since the JIT compiler has not yet been released and Android is operating with severe performance penalties compared to currently shipping iPhones (per your own metrics, 2-5x slower than with the JIT compiler) how has Android been able to grow so quickly? If I follow your argument than Android should be getting destroyed in the market right now because of its currently huge performance disadvantage in current models.
Let's posit a different argument — small performance disadvantages in method calling ABI are completely irrelevant compared to the actual performance, features, and user experience of the platform in consumer electronics devices (like smartphones).
It's really easy to criticize a platform you don't understand very well. Apple has been optimizing its runtime dispatch for a long long time. Reality is that messaging overhead is trivial in practice. And you have access to C/C++ when you need to maximize performance. (Apple's lower level apis are written in pure C.) Real old-school compiled (by the dev) code — you aren't going to beat that for performance. This is the equivalent of speaking of Java as an interpreted language.
The refresh cycle is overstated too. Real people buy a new phone about every 2 years… not every 3 months.
And every BIG Android feature seems to come at the expense of what Apple (as a maker of complete products not just technology) knows from years of experience is user issue #1: battery life.
====
But I digress. You're basically saying here that Compiled C can't keep up with the performance of Java. Fail.
Make sure you force garbage collection in Java
because otherwise it is not fair comparison. Also initialization of the VM.
This kind of B.S. worked when Apple purchased NeXT until Carbon
was deprecated. Now no Mac developer ever bad mouths Obj-C or Cooca.
First of all most of Java features were taken from Obj-C. including former NeXT
employees who wrote the abomination that base classes and AWT.
real work performance is different thing then cooked up benchmarks.
even Ruby can beat Obj-C.
If you need real example. look for WebObjects when it was written in Obj-C
and then when it went to Java. The amount of features that were lost.
FIrst web browser was written by TBL (a physicist) in Obj-C.
Android is your last hope. you poor poor Java developers. You better
pray that Google doesn't fuck up like Sun. Good thing that Java people
along with Flash people can cry all they want how big their private parts are.
“method calls in Objective-C are very slow”
I wrote a little test. You can see it at http://stefan.arentz.ca/2010/05/26/how-fast-are...
8.5 million method invocations PER SECOND.
Show some equivalent Java code running on Dalvik please.
“and you have to fallback to native code” – I don't think you understand how the iPhone works … Objective-C *is* native code.
The hardware in most Android phones is 2x what it is in the iPhone. This and AT&T explains why they are able to match sales.
The hardware in most Android phones is 2x what it is in the iPhone. This and AT&T explains why they are able to match sales.
I ran your test through Shark. Unfortunately, the Java bridge was deprecated a long time ago. Xcode will not compile Java now.
But you might be interested to know that objc_msgSend() — the dynamic dispatch function which you're disparaging — only accounts for 5.4% of the time it took to run the test. It's quite possible that Cocoa just needs some serious performance optimization.
Fortunately, it isn't anything like as important as you make it out to be. Cocoa enables the development of better code, faster, with access to better features, and is simply a more versatile language than Java. The AppKit framework is far more powerful than any comparable Java GUI toolkit, and looks a lot better. Sure, Apple could sink hundreds of thousands of person-hours into porting all the new Cocoa libraries (not to mention the underlying Core libraries like Core Foundation, Core Audio, Core Video, Core Animation etc.) to Java, but do you really think that that would pay off for them?
Hmm, I apologize, but I was reading the results incorrectly. The total time in objc_msgSend() was actually 19.5%. Sorry. Still, clearly not the cause of the discrepancy you found between Objective-C code and Java.
What hardware was that test run on?
iPad
Sam – you might be a bit out of date regarding Objective-C and garbage collection. Garbage collection is available in Objective C via the autorelease pool and has been since Leopard. However, in any language garbage collection is nice in theory but not necessarily great in practice. In Objective-C autorelease isn't a great idea if you wish to have strict control over your applications memory footprint. In mobile environments this is extremely important. Java garbage collection is also far from perfect. Tracking down and fixing memory leaks in Java can be extremely painful. The other problem is the lack of control over when it is run.
Personally I've found some of my greatest performance boosts (in an iPhone OS ObjC app) to occur by simply optimizing code or memory utilization. Nothing beats doing the hard work of performance tuning yourself. I would also argue that dropping down to C/C++ is a significant cost development-wise. You can easily write a mixed applications and target the faster languages at the performance critical parts of your application.
Of course if you're lazy you could simply leave it up to the OS to hopefully improve things (at some point, by how much unknown) instead of doing it yourself.
Garbage collection for Objective-C is not yet available on iPhone, only for real Mac OS X. I wish it was.
It is possible that the Cocoa libraries are also much slower than their Java equivalents. Far more time has been spent optimizing the Java libraries.
I guess OS X is doomed too then huh?
Linux beat out every single other Unix operating system on the server.
Fortunately OS X doesn't force you to write in Objective-C only for one, for two performance wise OS X does lose in virtually every benchmark (vs Linux / Windows implementations) but laptop/desktop performance has gotten to the point where it doesn't matter. It still matters on phones.
Objective-C calls are not compiled to machine code, they are dynamically dispatched through a runtime library. That is sort of the definition of non-native code.
And beat how many client operating systems? Last time I checked phones were not server systems.
In this case “optimizing your code” would involve forgoing the CoreFoundation methods which do string management, which would mean losing support for localization, which would be very costly to you as a developer. About 50% of the time spent in this test is taken up by Core Foundation. 12% or so by the actual memcmp() BSD function, and 19 or so by objc_msgSend() as I mentioned elsewhere, the rest is various. But this test is very contrived, in any case. It's nevertheless a fair point that the Mac OS X/iPhone OS libraries deserve more love. But switching it all over to Java? Ridiculous.
BTW, running this even more micro benchmark:
http://stefan.arentz.ca/2010/05/26/how-fast-are...
Results in a difference of 105x (Java over Objective C) on a Mac. I don't actually develop for Android so I can't run it there.
Really? Apple (and NeXT) has been optimizing for, what, 20 years? Even if you just count the time at Apple that's still 12 years. I don't see any real imperial evidence to support your argument.
After tweeting up a storm at the wrong user thought I'd just add my comments directly to the discussion here.
The fact of the matter is that the dynamic dispatch of ObjC is nowhere near as slow as one would think merely because it's a dynamic lookup. That dynamic lookup only ever happens the first time you ever call the method from which point it's hashed and invocation only requires one hash lookup. Apple has been optimizing this since 10.0, they've had 8 years to get it to just below the speed of direct method invocations in C++ and C.
ObjC has garbage collection, just not on iPhone yet, and if github is any indication the amount of ObjC libraries and code far eclipses java which makes sense since the language predates Java by nearly 10 years. The established expertise in the domain is far greater.
I still feel that the only reason why Google chose Java was specifically for this argument despite the fact that in the end it's really only the quality of the APIs themselves that matter.
After tweeting up a storm at the wrong user thought I'd just add my comments directly to the discussion here.
The fact of the matter is that the dynamic dispatch of ObjC is nowhere near as slow as one would think merely because it's a dynamic lookup. That dynamic lookup only ever happens the first time you ever call the method from which point it's hashed and invocation only requires one hash lookup. Apple has been optimizing this since 10.0, they've had 8 years to get it to just below the speed of direct method invocations in C++ and C.
ObjC has garbage collection, just not on iPhone yet, and if github is any indication, the amount of ObjC libraries and code far eclipses Java which makes sense since the language predates Java by nearly 10 years. The established expertise in the domain is far greater.
I still feel that the only reason why Google chose Java was specifically for this argument despite the fact that in the end it's really only the quality of the APIs themselves that matter.
Oh totally. Java's days are numbered*. (* to be measured in decades)
Or empirical as the case may be…
Or empirical as the case may be…
1. garbage collection using NSAutoreleasePool IS available on iPhone
2. objc 2.0 garbage collector is NOT available on iPhone, THANKS GOD.
ObjC *is* native code. You're essentially saying that C++'s vtable lookup is native code because it's compiled before compilation and method invocations are hardcoded, whereas moving essentially the same thing into code makes it “non-native” code. At no part in the Obj-C dispatch mechanism is it ever in a state where code isn't being directly executed on the processor targeted at the specific hardware it was compiled for. (this leaves aside the OS and processor working in concert to run code that wasn't compiled for it)
Hey Karl! Actually I disagree. Check out the pure dispatch benchmark below. Java (on the Mac) is over 100x faster to execute that code.
If only there had been some kind of progress in the past six years on the ObjC tools! Wouldn't it be awesome if ObjC were compiled into some kind of machine-agnostic bytecode, similar to the JVM, but lower-level so that you could also target C and C++ to it as well as ObjC… oh, wait, that sounds an awful lot like LLVM (which Apple has been investing in for years now, along with the new C/C++/ObjC compiler frontend for it, clang).
Seriously, it's not like Apple's just sitting around twiddling their thumbs. LLVM may not be perfect yet, but it's very neat tech, rapidly advancing, and can offer many of the same compelling potential performance improvements that Dalvik promises.
I didn't suggest switching the iPhone to Java. I think Apple needs to focus on performance of their Objective-C runtime and their core libraries or face an unnecessary performance gap.