Miscellaneous • furbo.org • Page 9

Benchmarking in your lap

It’s been a little over 2½ years since I last looked at the performance of Apple’s mobile devices. A lot has changed with the software and hardware since then, let’s take a look at how the new iPad compares to the devices we’re more familiar with.

Native performance

Test	iPad/3.2	iPhone 3GS/3.0	Faster by
100,000 iterations	0.000035 secs.	0.000137 secs.	3.91x
10,000 divisions	0.000010	0.000018	1.8x
10,000 sin(x) calls	0.000012	0.000018	1.5x
10,000 string allocations	0.004321	0.007915	1.83x
10,000 function calls	0.000338	0.000600	1.78x

This first benchmark compares the native performance of the iPad against the iPhone 3GS. The version of the iPhone OS is the one originally released with both devices (3.2 and 3.0, respectively.) The application used to test the devices was a release (optimized) build for ARM v7.

On average, the iPad is about twice as fast as the iPhone 3GS when executing native (Cocoa Touch) applications. Great news for developers, because it gives us much more flexibility when creating our apps.

JavaScript performance

Test	iPad/3.2	iPhone 3GS/3.0	Faster by
100,000 iterations	0.011 secs.	0.017 secs.	1.55x
10,000 divisions	0.006	0.012	2.00x
10,000 sin(x) calls	0.009	0.024	1.85x
10,000 string allocations	0.007	0.017	2.43x
10,000 function calls	0.005	0.006	1.20x

Oddly, the same 2x improvement is not seen for the same benchmarks when executing JavaScript code in web pages. Again, the iPad with 3.2 is compared against the iPhone 3GS with 3.0. Things have definitely improved, but there was a wide variation in results when performing the tests. I suspect that just-in-time compilation or other similar types of caching are affecting the results.

The raw numbers really don’t matter anyway: the browser experience on the iPad is exceptional (and will only get better.)

Native performance: Original iPhone vs. iPad

Test	iPad/3.2	iPhone/2.0	Faster by
100,000 iterations	0.000035 secs.	0.015 secs.	428x
10,000 divisions	0.000010	0.004	400x
10,000 sin(x) calls	0.000012	0.105	8,750x
10,000 string allocations	0.004321	0.085	20x
10,000 function calls	0.000338	0.004	12x

The most remarkable change is when you compare the original iPhone to the iPad. Using the numbers from my original tests and the results above reveals an improvement of several orders of magnitude in just over 2½ years. I believe the technical term for this is “Holy crap!”

Note: I don’t remember if the original tests were optimized builds, or if it was even possible to get gcc to do them with a jailbreak toolchain. Even if they weren’t optimized like the current tests, the performance increases are still stunning.

All-in-all, a remarkable achievement by Apple’s engineers, especially when you consider that the battery life of these devices has gone up, rather than down.

iPad hardware

When using sysctl() to query the amount of memory available to the iPhone OS, the following values are reported:

Kind	Bytes	Megabytes
Physical (HW_PHYSMEM)	258,998,272	247 MB
User (HW_USERMEM)	210,284,544	200.5 MB

Again, it’s likely that the device is using 256 MB memory chips with a portion of the total being used for other purposes, such as video memory. Also, developers have noted that all of the 200 MB of user memory is not available for use by apps. The OS and background apps make use of a large portion of that memory.

And last, and unfortunately least, we have the CPU speed reported by sysctl() using HW_CPU_FREQ. It’s zero: the A4 chip is truly magical. I guess that means we have to trust the spec sheet :-)

So hats off to the engineers in Cupertino: the iPad is an inspiring achievement no matter how you benchmark it!

P.S. Check out Twitterrific for iPad to see how we’re putting this processing power to use with our first app for this new platform.

P.S.S. If you’d like to perform these tests on your own, I invite you to download PantsTest.zip.

Written on April 3rd, 2010 for Miscellaneous

iPad liberation

I’m too busy right now to write about the iPad in detail, but I do want to make one quick point that I haven’t seen covered in other essays.

An important observation that I’ve made with the iPhone is that it’s perfect for “relaxed” computing. I use it while lying in bed, watching TV, waiting for my wife to try on a new outfit, driving through the middle of the desert, and a myriad of other situations where I’m not working.

There’s an inherent benefit to only doing one thing at a time: the load of worrying about other tasks is lifted. Knowing that there isn’t anything else competing for your attention is quite liberating.

Of course, the iPad is an extension of this.

What I find most interesting is the inclusion of the iWork applications. I suspect that we’ll all benefit from working in Pages, Numbers and Keynote without the distractions of the web, Twitter or chat. And in the long run, we’ll prefer it.

Written on January 29th, 2010 for Miscellaneous

An expensive lesson

One of my favorite sayings is “the best education comes from the school of hard knocks—if the tuition doesn’t kill you.” We’ve learned a very expensive lesson this week from a bug in iTunes.

The problem started when Pickin’ Time was approved on October 9th. We’ve all been busy working on other projects, so we delayed the launch until October 27th by setting the availability date in iTunes Connect. That gave us time to get the website and other promotional materials finished.

Unknowingly, it also gave us plenty of time to shoot ourselves in the foot. iTunes uses the date of approval as the “release date”, not the day you set for availability.

iTunesPickinTime

The result is that there’s no sign of Pickin’ Time in any of the “new” application lists: the casual browsers aren’t finding the app. There’s none of the momentum that’s so important in the App Store.

It’s frustrating that success, after months of hard work, can hinge on something unknown and completely out of our control. The customers who have found the product, are leaving great reviews [iTunes link]. It’s not a question of the game’s quality, it’s a problem of being lost in quantity.

Hopefully, this post will help another developer avoid this unenviable situation. We’d also appreciate any help in getting the word out about Pickin’ Time. Thanks!

Written on October 29th, 2009 for Miscellaneous

A phone by any other name would smell as sweet…

The general consensus is that there will be a new iPhone announced next week. I, like others, think it’s going to have new features and capabilities. But how is Apple going to label this new device?

iPhone 3G?

It’s entirely possible that Apple will keep the same name as the previous version. There’s precedence in the Mac product line: we’ve had MacBook Pros for several years now with various ways of distinguishing different product iterations (“Late 2008”, “Unibody”, etc.)

Given Apple’s reluctance to publish any of the device’s hardware capabilities, this would seem to make sense.

Except for one small problem. It’s likely that the new iPhone will have a faster processor and more memory. Some applications will be written to take specific advantage of these improvements. And that, of course, means that you need a way to let iTunes customers know if those applications are compatible with their device.

I don’t see Apple putting “iPhone 3G (2008)” and “iPhone 3G (2009)” anywhere in the iTunes UI. It’s just too confusing.

iPhone 4G?

What about having artificial product designations like they did with PowerPC desktop Macs: “G3”, “G4” and “G5.”

The problem here is that 3G refers to a network service, not a product generation. If this naming convention is used, customers are bound to wonder if a “4G” product works on their 3G network.

iPhone 3G Plus?

So maybe they do something like we’ve seen with the iPod product line. Using terms like “Classic”, “mini”, “nano” and “shuffle” to differentiate the products.

The problem here, of course, is that there’s only one product on sale. Unless Apple plans to keep the current product on sale (at a reduced price,) this just doesn’t make sense.

I’m not going to make any predictions on the device’s name, but I will be paying close attention. The ultimate choice is likely to offer some subtle clues regarding Apple’s plans to evolve this product in future revisions.

Written on June 4th, 2009 for Miscellaneous, Observation

Front Row To Go

Everyone and his brother has a prediction about Apple and the mythical “netbook.” This is mine.

Before I get into the actual prediction, let me say that I’ve come to this conclusion by looking at Apple as a business, not as a supplier of shiny gadgets for our technolust. As much as we love the things they make, their goal as a corporation is to make the stockholder’s happy. They do that by selling lots of products. We’re just a means to that end.

A lot of the speculation regarding the netbook says that it provides functionality in the price gap between a $200 iPhone and a $1000 MacBook. While that’s true, it misses the point.

Apple would rather sell you another device in addition to the ones they already sell. They’re not interested in cutting into (presumably healthy) MacBook sales with a netbook. Likewise, selling a bigger touch device could cut into iPhone sales: keep your crappy cell phone and buy the netbook to throw in your purse or backpack.

One of the things that saved Apple was a simplified product line based around professional and consumer uses. Does it really make sense to have more than one consumer-level device for laptop computing? The MacBook already kicks ass in that department: having another device in that category just muddies the water.

But what if there was a device that could work in conjunction with your other Apple products? Something that extended their capabilities. Something that made each product better for a few hundred dollars.

Apple and their shareholders would love this: you’d buy the iPhone and the “netbook”. And eventually the MacBook. And maybe an Apple TV. And probably an iPod, too.

So what are some of the problems with the current hardware lineup?

iPhone / iPod touch – Small screen, small keyboard.
Mac – No touch screen, running Front Row prevents using your Mac for other things.
Apple TV – crappy remote, no keyboard.
iPod – Very small screen with no touch screen or keyboard.

So what kind of product could fill in these gaps? I call it “Front Row To Go.” Think of it as a second screen for the current hardware. Something that could:

Display photos on a larger screen than on the iPhones and iPods. It would also be effective as an adjunct to iPhoto on the desktop: Microsoft’s Surface prototype shows how effective it is to display pictures on a horizontal surface that can be manipulated by multiple viewers.
Provide a touch screen keyboard for the iPhone and Apple TV: a better input mechanism than hunting and pecking on chiclets. (Maybe this is the reason Bluetooth keyboards aren’t available for the iPhone.)
Show movies on a larger screen: anyone who’s taken a transoceanic flight knows that looking at the iPhone/iPod screen for more than a couple hours can be quite tiresome. An added benefit is that the player’s battery wouldn’t be consumed by the display’s power needs.
Provide touch input to desktop applications. Multi-touch is never going to happen on a vertically oriented display, so make a separate device that works horizontally. An obvious benefit to developers is that they don’t have to rewrite code: if it makes sense, multi-touch can be added to enhance current applications.

As with all other Apple products, Front Row To Go could obviously work as a standalone device. Sync your content onto the device and take it with you: no more dragging a laptop to a family reunion just because Aunt Bessie can’t see the tiny photos on the iPhone. Get your bookmarks and feeds from the Mac and surf the web using Front Row To Go’s version of Safari while you’re listening to music or watching TV.

As far as how these features would be implemented, that’s anyone’s guess. There might be an API for developers, or maybe it’s a closed system. The device might be able to play iPhone games or run multiple iPhone applications at once (much like the current Dashboard works in Mac OS X.) With a common base of OS X running throughout the product line, pretty much anything is possible.

And that gets to the real point of this essay: think about what Apple has learned from the halo effect surrounding the iPod (and now the iPhone.) If you have any doubt that this effect is alive and well, drop into an Apple Store on any weekend and take a look around: plenty of customers who are happy with one product and looking at others.

In my opinion, these consumers are the ones that Apple will target with a “netbook,” not the ones that are jonesing for a sexy little machine that fills a perceived gap in the product range. I hope I’m right, because I’d love to be one of those customers lining up to buy Front Row To Go.

Written on March 16th, 2009 for Miscellaneous, Observation, Opinion

Category: Miscellaneous