Occipital

Similarity transforms come up often in computer vision and gestural interfaces.  The results below are a straightforward application of definitions, but didn’t come up in a quick web search, so I though they may be useful to document here on the blog.

In 3×3 matrix form, a similarity transform parameterized by a scale, rotation, and translation is represented as:

[s*cos(th)  -s*sin(th)   tx ]
[s*sin(th)   s*cos(th)   ty ]
[    0           0       1  ]

Say you have two similarities, T1 and T2, with their parameters as follows:

• scale: s1,s2
• rotation: th1,th2
• translation: (dx1 dy1), (dx2 dy2)

We had a great time this summer as one of the 10 companies that participated in TechStars. I took a lot of photos, and I finally got around to uploading them to the internets. However, these photos are a skewed view of TechStars because I mostly took photos when we weren’t working. So consider the following photos mostly a story of the 5 to 10% of the time we were goofing off.

Our team from the summer. Left to right: Gandhi, Jeff, Vikas, and Shun. This is actually one of Andrew Hyde’s photos.

Soul Patch Concert

Unwinding at the St. Julien after the first demo day:

TravelFli showing off their EntrepreneurWear t-shirts, a counterpoint to VCWear.

Foodzie with Howard Diamond, one of the TechStars mentors.

Rock Band! Andrew Hyde is rocking out on the drums as usual.

Our official company book, it goes everywhere with us.

Andrew Hyde and Jeremy Tanner hanging out at the Bunker.

Jeff and I on stage at Boulder New Tech Meetup.

Hungry entrepreneurs feasting on Foodzie food ferociously. Alliteration anyone?

Tailgating in the parking lot before a Live/ Blues Traveller concert at Red Rocks with Ignighter.

Team Ignighter vs a hybrid Occipital / TravelFli team in a beer pong tournament at our house on the Hill in Boulder. This tournament was where BHARD was born.

Samantha Murphy, the Highway Girl, being amazing on stage at the Laughing Goat.

Our sublet for the house on the Hill ended 2 weeks before the final demo day, and luckily Foodzie let us crash at their place. Gandhi and I slept on the living room floor. Here is Gandhi curled up on the living room floor.

Shun and Jeff slept in the extra bedroom.

Practicing for demo day:

Foodzie’s awesome and adorable dog, Bently, who woke us up every morning in the living room.

The team practicing for demo day:

TravelFli prepping for demo day:

Foodzie with Brett Jackson.

A pizza box with a phrase very similar to “BuyPlayWin“.

Finally it’s Demo Day! Here’s Jeff on the way to the theater.

Team Ignighter looking sharp. Adam, the one in the futuristic coat, is saying “this guy knows what I’m talking about!”

TravelFli dressed appropriately.

Jeff presenting.

And then to unwind! Here we are at the Kitchen Upstairs.

Molly eating an entire ramakin of ketchup (thanks for teaching us that word Austin!).

Austin asking “who wants to go to Houston?”

Nerding it up at the Bunker by playing StarCraft with Devver and BuyPlayWin.

Occipital Founders vs Interns ping pong battle.

David and Jill Cohen invited us all to their beautiful house for an end of TechStars party.

David Cohen, executive director of TechStars, manning the grill. He’s saying “eat more, faster!”

T-Shirts from some of the companies.

Joe “two beer” McVicker from App-X talking to Tom Keller of IntenseDebate.

Ben from Devver saying to his girlfriend, “I’ve got something really important to tell you, my real job is as a backup Britney Spears dancer.”

And here is Ben showing off those dancing skills in the Cohens’ backyard.

And finally, the team at the end of TechStars having a well earned drink. It took me the entire summer to get Shun and Gandhi to drink with us. We miss you guys!

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.