Year: 2010

An apology…

Until Gizmodo publicly apologizes to Gray Powell, this is going to be in my /etc/hosts and in all of the DNS servers under my control:

127.0.0.1	gizmodo.com
127.0.0.1	www.gizmodo.com
127.0.0.1	m.gizmodo.com
127.0.0.1	gawker.com
127.0.0.1	www.gawker.com
127.0.0.1	m.gawker.com

The person at fault is the shithead who stole the phone, not some overworked engineer drinking beer.

Please vote with your attention and do the same. Thanks!

(Thanks to @sebastianlewis for the idea.)

Update: I can’t believe there are some people defending Gizmodo’s actions. Let’s put the shoe on your foot:

  1. You’re drinking beer with some friends.
  2. You leave your wallet behind at the bar.
  3. Some stranger finds your wallet and opens it up. Inside is a naked picture of your partner.
  4. That stranger finds a website that wants to post the picture and they sell your wallet intact for $1.
  5. Your partner finds their naked body on the Internet. Shit hits the fan. HARD.
  6. The site that posted the pictures looks at the ID in the wallet and calls up with an offer to return the wallet. “Don’t worry, all the money’s still there!”
  7. Then that website posts another article saying how dumb you were for leaving your wallet behind. And instantly millions of people associate your name with a stupid mistake.

How do you feel now?

Update: If you’re the kind of person who forgets that you edited your hosts file, use Marco Arment’s IP address of 66.135.33.106 instead of 127.0.0.1.

Update: For those of you who don’t feel comfortable with the Terminal, here’s a Cocoa application that runs an AppleScript to block Gizmodo. Thanks @digdog!

Written on April 19th, 2010 for Miscellaneous

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

UDID not

Here we are on the brink of a new iPhone OS product introduction and developers are facing yet another crunch with device IDs for Ad Hoc testing.

Apple currently lets each iPhone developer, whether a company or an individual account, assign 100 devices for testing purposes. A large chunk of those available devices get used by employees with multiple devices. We also have a valuable group of external testers that we use for Ad Hoc beta testing. Many of these individuals buy the latest and greatest hardware, so each time there is a new product introduced, we use up more devices from our list.

On April 3rd, almost everyone on our beta test list will be buying an iPad and want to run Twitterrific on it. Unfortunately, some of these testers are going to be out of luck because we don’t have enough devices left to allocate. I have no idea what we’re going to do if the next version of the iPhone OS is introduced before our iPhone Developer account gets renewed.

As a developer, I never like turning a valuable tester away from my product. But that’s what we’re doing now.

To be clear, I think Apple’s policy is justified. Developers were abusing the system, so something had to be done. The problem, in my mind, is that the throttling valve is being put on the wrong piece of pipe.

As developers, we want to maintain a pool of testers, not devices that they test on. Devices are ephemeral: they change as new hardware is introduced and replaced. The thing that remains constant are the people who test our products.

A tweet from Mike Piontek crystalized this thought: the limitation for Ad Hoc provisioning should be based around individuals, not the devices that they own. It makes more sense to regulate Apple IDs rather than UDIDs. I want John Gruber to be able to run my apps on whatever devices he currently owns. I want to put my own name on the provisioning list and enable the five iPhone OS devices sitting on my desk. All that Apple cares about is that are only 98 other people besides Gruber and me.

(I suspect that Enterprise IT has similar problems and would welcome a solution based on employees rather than the hardware they own. I can only imagine the headaches of managing thousands of devices.)

Of course, there’s a huge amount of infrastructure around verification based on UDIDs: the Program Portal, device firmware, and our own internal processes would require changes. But I think it’s a good goal to work toward, because the current system isn’t scaling well and will only get worse as Apple introduces new products.

Updated April 13th, 2011: It’s been over a year and the situation just keeps getting worse. Please take a moment and duplicate rdar://9255432. Thanks!

Written on March 22nd, 2010 for Business, Development, Observation

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
Newer