iOS Obj C vs Java (or, iOS vs Android)

[mikethebigo]

Hi everyone,

So I'll start by saying, PLEASE, I'm not trying to create a flamewar, or criticize either of these exceptional mobile operating systems. Actually, I own an iPhone 4 and a Nexus S, and think they're both great.

My friends and I just had a technical question that I was hoping someone could answer/help explain, especially since many posters on here are long time developers.

I know that iOS programs are written in Obj C/C++/C and are all natively coded. On the other hand, Android operates through a Java virtual machine (Dalvik), although since Froyo it's been a JIT implementation that I suppose is much faster (though I've never completely understood how JIT works).

So my question is, currently, is one programming language significantly more efficient than the other? Will native code always run faster and smoother than the code in the Android virtual machine, or are they about equal now? The only stuff I could find online in comparison was javascript performance, and those benchmarks were done with different hardware so they were pretty much useless. I was thinking more on the abstract or overall level if one was significantly better than the other.

Any explanations about the two systems would be wonderful just because I'd like to understand a little deeper into the OSes I'm using.

Again, PLEASE no flamewars! They're both good! Thanks everyone.

 

[torbjoern]

The languages Obj C / C / C ++ have function calls which go directly to the operating system. This is the reason why a program written in C for Windows doesn't necessarily execute properly (or even compile) under UNIX/Linux.

Java apps are run on a virtual machine, which makes it possible to execute the code on practically any computer with JVM installed; the calls to the OS will be done by the VM. The most significant disadvantage with this solution is that it takes longer time to execute the program via JVM.

In other words: C is faster, while Java is more interoperable.

 

[robbieduncan]

In other words: C is more efficient, while Java is more interoperable.

Sometimes. Sometimes not. If we look at the desktop case we normally compile C to a lowest common denominator target, say 386-era x86 (or even 586 era x86). This means our C doesn't use all of the advanced features on the CPU. Java on the other hand is JIT compiled. So it gets compiled to the same level as the C code, but targeted explicitly for the architecture it's running on. For interactive code/short running programs the JIT overhead may be enough of an issue to wipe out this potential advantage. On server code Java is frequently faster than compiled code.

Looking back at the question posed this theoretic advantage of Java is not really there: our iOS apps are compiled to the exact architectures they run on. So they could be more efficient that Java. But Android doesn't run Java: code is written in Java but the compiler doesn't output standard Java bytecode. The runtime is Dalvik which is a bit different.

 

[mikethebigo]

Sometimes. Sometimes not. If we look at the desktop case we normally compile C to a lowest common denominator target, say 386-era x86 (or even 586 era x86). This means our C doesn't use all of the advanced features on the CPU. Java on the other hand is JIT compiled. So it gets compiled to the same level as the C code, but targeted explicitly for the architecture it's running on. For interactive code/short running programs the JIT overhead may be enough of an issue to wipe out this potential advantage. On server code Java is frequently faster than compiled code.

Looking back at the question posed this theoretic advantage of Java is not really there: our iOS apps are compiled to the exact architectures they run on. So they could be more efficient that Java. But Android doesn't run Java: code is written in Java but the compiler doesn't output standard Java bytecode. The runtime is Dalvik which is a bit different.

So, Java has the advantage of being targeted at a specific platform, but that advantage disappears when comparing to iOS because those programs are also compiled for specific hardware?

I'm curious, is conversion that makes the JIT code run at the machine level happen when you're writing and compiling the program, or is the virtual machine still actively converting Java code to native code? This stuff is really interesting to me.

 

[robbieduncan]

I'm curious, is conversion that makes the JIT code run at the machine level happen when you're writing and compiling the program, or is the virtual machine still actively converting Java code to native code? This stuff is really interesting to me.

The JIT (just-in-time) compiler is part of the JVM. The Java compiler produces java bytecode. This is portable and will run on any JVM. Some JVMs have JIT compilers in them, some don't. As the JIT takes time to execute SUNs (now Oracles) hotspot JVMs look for the parts of the code that will make the biggest difference when compiled to native code (the hot spots within the code).

This old article dates from the introduction of the JIT technology to Java and provides an overview. The current JVM has lots of additional "clever stuff" to speed it up.

 

[mikethebigo]

The JIT (just-in-time) compiler is part of the JVM. The Java compiler produces java bytecode. This is portable and will run on any JVM. Some JVMs have JIT compilers in them, some don't. As the JIT takes time to execute SUNs (now Oracles) hotspot JVMs look for the parts of the code that will make the biggest difference when compiled to native code (the hot spots within the code).

This old article dates from the introduction of the JIT technology to Java and provides an overview. The current JVM has lots of additional "clever stuff" to speed it up.

Cool article! I'm still working through it, but one thing that jumped right out to me on the first page was:

"Sun's new HotSpot technology, due to ship this summer (with a developer release due sooner), is a dynamic compiler -- a compiler built into the virtual machine that promises to run as fast or faster than compiled code in the majority of applications."

So that seems to answer my original question as well, they seem to be just about equal in processing speed!

 

[John.B]

The languages Obj C / C / C ++ have function calls which go directly to the operating system. This is the reason why a program written in C for Windows doesn't necessarily execute properly (or even compile) under UNIX/Linux.

Java apps are run on a virtual machine, which makes it possible to execute the code on practically any computer with JVM installed; the calls to the OS will be done by the VM. The most significant disadvantage with this solution is that it takes longer time to execute the program via JVM.

In other words: C is faster, while Java is more interoperable.

Even if this whole "Java is more interoperable" mantra were true (which it's not -- without going to great pains to make it so), the write-once-run-anywhere sales pitch doesn't actually work like that IRL. If you don't believe me, go ask a corporate Java developer; most Java is done server-side and not client-side, and is written with specific environments and libraries in mind.

Also, Android "borrowed" the Java language (without asking) but uses the Dvalik VM which is only JVM-like. And, if Google loses the Java lawsuit to Sun/Oracle, you'll have to learn another language instead of Java to continue to do Android development.

Finally, most iOS coding for iPhone/iPad applications is done with Obj-C and Cocoa Touch, not C or C++.

HTH

 

[dccorona]

Even if this whole "Java is more interoperable" mantra were true (which it's not -- without going to great pains to make it so), the write-once-run-anywhere sales pitch doesn't actually work like that IRL. If you don't believe me, go ask a corporate Java developer; most Java is done server-side and not client-side, and is written with specific environments and libraries in mind.

Also, Android "borrowed" the Java language (without asking) but uses the Dvalik VM which is only JVM-like. And, if Google loses the Java lawsuit to Sun/Oracle, you'll have to learn another language instead of Java to continue to do Android development.

Finally, most iOS coding for iPhone/iPad applications is done with Obj-C and Cocoa Touch, not C or C++.

HTH

yea but honestly, they'll either win or pay. They wont drop the language their marketplace is built around

 

[mikethebigo]

Even if this whole "Java is more interoperable" mantra were true (which it's not -- without going to great pains to make it so), the write-once-run-anywhere sales pitch doesn't actually work like that IRL. If you don't believe me, go ask a corporate Java developer; most Java is done server-side and not client-side, and is written with specific environments and libraries in mind.

Also, Android "borrowed" the Java language (without asking) but uses the Dvalik VM which is only JVM-like. And, if Google loses the Java lawsuit to Sun/Oracle, you'll have to learn another language instead of Java to continue to do Android development.

Finally, most iOS coding for iPhone/iPad applications is done with Obj-C and Cocoa Touch, not C or C++.

HTH

Them be fightin words! I'm actually interested in the intra-operability level of Java, as I've been following the news of the Dalvik VM that's being written for Meego, it sounds like someday you could run Android apps on it (if a phone with Meego ever actually comes out, haha). Similarly, I wonder if it will ever be made possible to run all Android apps on your primary computer (like the Atrix is doing with WebTop).

I do know Google kinda stole some of Java, but I also know it's a complicated story that will be stuck in litigation for a very long time. And at most, I feel like Google will just have to pay out some money. But I guess we'll see what happens with that.

I wonder if Apple will ever merge iOS so that you can use its apps in OSX. Cross-platform transportability is pretty cool stuff. What I'm afraid of though is Apple will refuse to innovate in certain ways because of monetary interest. Look again at the Atrix - seems to me that eventually all computers could be just phones plugged into screens when a larger UI is needed. But then Apple would stop being able to sell MacBooks and a large profit source would disappear.

But I digress! This is supposed to be about programming language performance. I've always told people Android will be slower than iOS due to being in a VM instead of native. It seems I'm wrong. It seems that as soon as Android implements hardware graphics acceleration, it could function just as smooth as iOS.

 

[KnightWRX]

I do know Google kinda stole some of Java

Don't believe everything you read on the Internet. Google has not been proven to have stolen anything from Sun Microsystems/Oracle. They are being sued on some patent claims for the Dalvik VM (which is not Java at all) and a few copyright claims that have not been made public. The few slip ups of copyrighted code that people found were not part of the Android distribution, see the Florian Mueller debacle where he got taken to school on it. Since the files he found were not part of the Android distribution per say, it has 0 impact on shipping handsets/devices.

Also, how did Google steal what is essentially licensed in a Free manner ? See the Java Language Specification license :

http://java.sun.com/docs/books/jls/third_edition/html/jcopyright.html

An important note : Sun gave away the right for 3rd party implementation of the language. No one has to ask for permission to write a Java language implementation as long as they respect that license. I don't see why Google would be held to a different standard. If Sun had wanted to be asked about it, they wouldn't have licensed it in that manner.

And the Apache Harmony runtime they use for their J2SE layer is of course licensed under the Apache License.

Leave the lawyering and verdicts to the court and remain objective. No one can claim Google did anything wrong as it stands right now, this is entirely still up to the courts to decide.

 

[firewood]

Compiled code runs faster and more efficiently than interpreted code. Any Java JVM without a JIT will run code several times slower than compiled code.

A JVM with a JIT will produce faster code, but will consume a more energy and time running the JIT itself instead of just your code. Whether the JIT or the XCode LLVC compiler will produce a more efficient code depends on the code and the data set, but usually an optimizing compiler can spend more time and memory optimizing, do more global optimization, and thus produce faster code than a hot-spot JIT.

If an app spends most of its time in OS calls, none of the above makes much difference.

 

[mikethebigo]

Compiled code runs faster and more efficiently than interpreted code. Any Java JVM without a JIT will run code several times slower than compiled code.

A JVM with a JIT will produce faster code, but will consume a more energy and time running the JIT itself instead of just your code. Whether the JIT or the XCode LLVC compiler will produce a more efficient code depends on the code and the data set, but usually an optimizing compiler can spend more time and memory optimizing, do more global optimization, and thus produce faster code than a hot-spot JIT.

If an app spends most of its time in OS calls, none of the above makes much difference.

So in the Dalvik VM case, are you agreeing that it's just about as efficient as native code? If this is the case, I wonder if the lag Android experiences in its UI is completely due to lack of hardware acceleration.

 

[firewood]

So in the Dalvik VM case, are you agreeing that it's just about as efficient as native code? If this is the case, I wonder if the lag Android experiences in its UI is completely due to lack of hardware acceleration.

I would just run some benchmarks and measure the difference in execution time for your code of interest.

The JIT itself can cause lag, as it consumes CPU and memory resources. But there are lots of other reasons for UI lag than an app's raw CPU performance.

 

[chown33]

The JIT itself can cause lag, as it consumes CPU and memory resources. But there are lots of other reasons for UI lag than an app's raw CPU performance.

There's also a difference between lag and jumpiness.

Dalvik is a garbage-collecting architecture. iOS is not. GC can interrupt to collect garbage at points that interfere with smooth UI real-time operation.

 

[mikethebigo]

I'm working on understanding garbage collection more a little now. It's weird, I thought I read somewhere that xcode would include garbage collection as well once Leopard came out. Is that not true?

Interesting (and still someone relevant) revelation I had tonight: Watson, the IBM supercomputer on Jeopardy, runs on Java!

 

[cnstoll]

I'm working on understanding garbage collection more a little now. It's weird, I thought I read somewhere that xcode would include garbage collection as well once Leopard came out. Is that not true?

OS X does have garbage collection. iOS does not.

 

[chown33]

Interesting (and still someone relevant) revelation I had tonight: Watson, the IBM supercomputer on Jeopardy, runs on Java!

Watson has a wee bit more computational capability than any Android or iOS device:

Watson is made up of a cluster of ninety IBM Power 750 servers (plus additional I/O, network and cluster controller nodes in 10 racks) with a total of 2880 POWER7 processor cores and 16 Terabytes of RAM. Each Power 750 server uses a 3.5 GHz POWER7 eight core processor, with four threads per core. (Emphasis added)​

http://en.wikipedia.org/wiki/Watson_(artificial_intelligence_software)#Overview

The tradeoffs for choosing and using a computer language are also a wee bit different.

BTW:

Watson's programming was written in both Java and C++ ...​

per Wikipedia article.

 

[afs_nj]

Finally, most iOS coding for iPhone/iPad applications is done with Obj-C and Cocoa Touch, not C or C++.

This is the major most equalizer when comparing performance between the java stuff and the ios stuff. Many articles on the net dance around performance issue, but all essentially lead to the same conclusion--the efficiencies of most any ios app written in C++/C, almost always exceed any java implementation, and almost always translates to better performance. I don't care about others' 'flame wars' -- as it stands now, you need to throw more CPU horsepower at a java/android app for it to run as well as a C/ios app.

 

[Duncan C]

Watson has a wee bit more computational capability than any Android or iOS device:

Watson is made up of a cluster of ninety IBM Power 750 servers (plus additional I/O, network and cluster controller nodes in 10 racks) with a total of 2880 POWER7 processor cores and 16 Terabytes of RAM. Each Power 750 server uses a 3.5 GHz POWER7 eight core processor, with four threads per core. (Emphasis added)​

http://en.wikipedia.org/wiki/Watson_(artificial_intelligence_software)#Overview

The tradeoffs for choosing and using a computer language are also a wee bit different.

BTW:

Watson's programming was written in both Java and C++ ...​

per Wikipedia article.

A well-tuned Java implementation using JIT compiling to machine code is only a few percent slower than a true compiled language like C, C++, or Objective C.

It's my understanding that on desktop platforms like Mac OS and Windows, the Java runtime is such a finely tuned virtual machine.

I don't know enough about Android to be able to speak authoritatively about performance. I would bet that the difference is fairly minor however.