No stupid YouTube video like previous attempts at proving this, just some clean console output (trimmed):


x  688, y 3921, z  17, w  1, F 0, 2nd: x    0, y    0, z  17, w  1,
x  696, y 3892, z  21, w  1, F 0, 2nd: x    0, y    0, z  21, w  1,
x  700, y 3887, z  24, w 13, F 0, 2nd: x    0, y    0, z  24, w 13,
x  700, y 3868, z  53, w  7, F 2, 2nd: x 2859, y 1168, z  53, w  7,
x  697, y 3867, z  61, w  6, F 2, 2nd: x 2863, y 1162, z  61, w  6,
x  692, y 3864, z  64, w  7, F 2, 2nd: x 2863, y 1166, z  64, w  7,
x  683, y 3860, z  67, w 10, F 2, 2nd: x 2867, y 1170, z  67, w 10,
x  677, y 3857, z  68, w 11, F 2, 2nd: x 2867, y 1170, z  68, w 11,


Here’s the benchmark converted into objective-C:


NSDate *start = [NSDate date];
int arr[8*320*480];
for(int i = 0; i < (8*320*480); i++)
arr[i] = i;
NSDate *end = [NSDate date];
NSLog(@"%g", [end timeIntervalSinceDate:start]);

Results:

• iPhone (2.1 firmware, Objective-C): 9.5 milliseconds

And, from last time:

• G1 (R29 firmware): 922 milliseconds.
• G1 (R29 firmware): Loop only. 520 milliseconds.

Conclusions:

Objective-C kills the Java implementation on Android.  It’s almost exactly 100 times faster.  Note that I’m unsure if the memory allocation is included in the timing, so a more conservative statement is that Objective-C can run a tight loop 50 times faster than the Dalvik JVM.  It’s also true that real applications aren’t full of tight loops, and a real Android application won’t be 50 times slower than an iPhone counterpart.  Nevertheless, all else being equal, it will be slower, and potentially a lot slower.

For now, we’re sadly going to put our Android development on hold and switch to iPhone, and keep an eye out for performance improvements.

I had noticed that Android was running on some Java virtual machine called Dalvik, but hadn’t given it much attention otherwise.  It turns out to be pretty important, after all.  As far as I can tell, Google decided it would be a good idea to favor a small memory footprint over speed.  Here’s the benchmark I just performed:

long start = android.os.SystemClock.uptimeMillis();
int[] image = new int[8*320*400];
for(int i = 0; i < (8*320*480); i++) {
   image[i] = i;
}
long end = android.os.SystemClock.uptimeMillis();
long elapsed = end - start;

So, how long did it take?

• G1 (R29 firmware):  922 milliseconds.
• G1 (R29 firmware).  Loop only.  520 milliseconds.

And, for comparison:

• Fujitsu T4220 (2.4 GHz Intel T7700).  C#. 14 milliseconds.
• Fujitsu T4220 (2.4 GHz Intel T7700).  Java. 16 milliseconds.

Note: I ran everything in “Run” mode (not Debug mode).  (Debug mode causes the G1 to run about 4X slower in this benchmark.)

Conclusions:

Dalvik puts a big wall between you and the (already pretty slow) CPU.

It is claimed that Dalvik is designed for slow machines with low memory, powered by a battery.  However, I don’t understand how the Dalvik interpret-only VM actually achieves this, other than through programmer castration.  What does that mean?  Well, you can’t really do much on Android that isn’t built into the runtime, or your application will crawl, and you’ll be forced to strip those features out and rely on the optimized ones that are built into the libraries.  The memory footprint for Dalvik is lower, because there’s no JIT compiled chunks of code sitting in RAM.  But isn’t RAM cheap, fast, and low-power these days?

Next time (Android performance 3):

• A duel with the iPhone.  I’d like to run this same trivial benchmark on an iPhone in Objective C and see what happens.

The best way to start, I think, is to just list the hardware specifications (from Wikipedia).

• CPU: Qualcomm MSM7201A (MSM7200 details)
• 528 MHz.  ARM11 (same family as iPhone).
  274MHz ARM9 coprocessor (not really “dual core” as is commonly claimed).
  Java hardware acceleration but not on the Dalvik VM (Android).
• GPU: (Shared with CPU)
  Capable of 4M triangles/sec.
  Capable of hardware-based image signal processor and JPEG encoder.
• Video Decoding:
  Chip supports 30fps VGA in
  MPEG-4, H.263, H.264, Windows Media® and RealNetworks®
• Video Encoding: (Not yet available on Android!)
  Chip supports 30fps VGA in
  MPEG-4, H.263 and H.264
• Network speed:
  Supports T-Mobile UMTS (3G) 800/1700/2100 MHz
  Possibly supports AT&T UMTS (3G) 850/1900/2100 MHz.  This disassembly shows the RTR6285 radio chipset, which supports both 3G platforms.  However, there are two power amplifiers — one at 2100 MHz, and one at 1700 MHz (T-Mobile frequencies).  Nevertheless, I don’t think the 1700 MHz amplifier attenuates 1900 MHz.  Look at the datasheet and see what you think.  So AT&T 3G would probably have a reduced range, but I think you could make it work.

There are a few open questions I’d like to answer related to this specification list.  Can the G1 support AT&T 3G (see above)?  Does the Android JVM benefit from the CPU’s Java hardare acceleration?  Does the JPEG encoding (Bitmap class) on G1 tap into the hardware?

We should also run a series of benchmarks and compare the Qualcomm processor’s Java performance, to, say, an Intel Core 2, for a number of tasks.  That way we can roughly estimate how fast something will run on a G1 before actually porting and deploying.  If you’ve seen any benchmarks like this, let me know, so we don’t reinvent the wheel!

Next time (Android performance 2):

• Benchmark for a simple array-indexing loop.