Occipital

There has been a lot of uneducated speculation about whether the Android G1 could support multi-touch.  I just came across this post by a smart guy who recompiled the synaptics touchscreen driver and got it to track two fingers. Bravo!

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,


We need things to go fast.  Really fast.  So when came across Ryan Block’s old post about the iPhone’s vector floating-point coprocessor, I was encouraged.  But how to access this new coprocessor?  I was excited to find some examples on Matthias Grundmann and Wolfgang Engel’s Google code project, vfpmathlibrary.

They’re just getting started and only have 4×4 matrix operations coded up so far.  Hopefully we can collaborate with these guys to expand the library and do some performance testing on different applications.  More to come on that.

I just came across Miguel de Icaza’s post about recent Mono performance enhancements.  I’m very happy to see all of the innovation in the C# language by Microsoft (see C# 4.0), but the .NET runtime isn’t getting any faster, unless you’re a dynamic language guy.

However, the Mono runtime is getting faster.  They’ve got static compilation, a brand new JIT compiler, and a framework extension so you can easily take advantage of the SIMD (vector) operations that have been available on Intel CPUs for a decade.

A simple way to think about it is that, for instance, you could use the Vector4f class (4 floats) and perform a floating-point vector operation four times faster.  I can’t wait to work with the new Mono.

The internet is just incredible. Within 30 minutes of logging onto the #iphonedev IRC channel on freenode, I got timing results for the iPhone on the simple loop benchmark from my last post. Thanks to ‘august’ for the help.

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.

Let’s run a simple benchmark on the G1.

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.

We are starting to develop on Android. The first Android device, of course, is the HTC/T-Mobile G1. We got one of the units this week, and I am just starting to look into exactly how fast the G1 runs. Performance is a hard thing to measure, but I wanted to start blogging about it in the hopes we can start a discussion and learn more about how to best measure and optimize performance on Android devices.

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.

We decided to get an Android G1 phone for work, and it arrived today. I was excited that we had already received two text messages!

But not so happy when we looked closer. One was a message from T-mobile, sent yesterday, telling us what the phone’s number was. Useful — timely. The other message was from “FStick13″, also sent yesterday. Not so useful — but timely. Nice work, spammers, you beat the delivery guy. If only your talents were used for something a little more positive.

We moved to Boulder about 4 months ago to participate in TechStars. Before getting here, I didn’t know much about Boulder except that it was a liberal city near the mountains and it was home to the University of Colorado, the team that beat my beloved Wolverines in 1994.

What we found was a thriving tech startup community nestled up against the beautiful foothills of the Rockies. The tech community here is incredibly supportive and filled with smart, interesting, and fun people. The mountains are beautiful, the air is clean, people are healthy, and the local beers are awesome.

If you want to experience Boulder for yourself, 20 boulder tech startups are hosting an all expenses paid job fair for 100 kickass developers. Here’s what TechCrunch had to say.

One of the things I’ve often read about doing a startup is that there are amazing highs and disappointing lows. We’ve definitely had our share of both, and when things get tough I think about why I’m doing this.

What gets me out of bed in the morning (or afternoon if we’ve been up late working) is that we’re working on hard, interesting problems that have the potential to change the world in some way and that I get to work with one of the smartest people I know. It also helps that I have the support of my amazing family, awesome friends, and how we’ve become part of the great tech community here in Boulder (which means more friends and smart people!).

We’ve got some exciting things on the way here at Occipital, so bring on the lows - they’ll make the highs we reach even sweeter.

I think that a search for elements of nature on flickr is probably the most fruitful ways to find great, unique, desktop wallpaper.  Certain elements in nature are better than others, however.  I think sunlit water droplets on leaves are curiously perfect for desktop backgrounds.  Search for “leaf droplets”

Shimmering sunlit droplets with fisheye world reflection, held by surface tension to the epidermis of a leaf.  Or a series of droplets perfectly distributed by the leaf’s vein structure.  These typically macro mode photos will also have a perfectly blurred background, further enhanced if taken with SLR cameras, so they won’t obscure icons.  You really have to be a bad photographer to mess up this shot.

What other nature searches produce brilliant wallpaper?