The Palm Pre’s Hardware
I’ve gone through this performance comparison once before but I’ll quickly summarize it here. The iPhone and iPhone 3G both use an ARM11 based CPU running at 412MHz. The Palm Pre uses an ARM Cortex A8 based CPU running at 600MHz. The Cortex A8 is significantly faster than the ARM11; while both are very simple in-order cores, the A8 is capable of fetching/decoding/executing/retiring two instructions at the same time - the ARM11 can only do one. Palm has the overwhelming raw horsepower advantage with its hardware, as it should, the Pre was designed much later than the original iPhone (note that the new 3GS should match the Pre in terms of hardware prowess).
Given the incredible performance advantage of the Pre’s hardware, you would expect it to be much faster than the iPhone 3G. Unfortunately, that’s only partially true. Let’s start with some basic application tests:
|Application Launch Time in Seconds||Web Browser||Dialer||Google Maps||Camera|
|Apple iPhone 3G (3.0)||1.1 s||1.7 s||3.8 s||4.6 s||1.2 s|
|Palm Pre||3.0 s||1.5 s||8.6 s||4.4 s||3.3 s|
|T-Mobile G1||5.4 s||2.0 s||4.4 s||4.9 s||2.0 s|
Despite a significant processing power advantage, the Pre launches most applications slower than the iPhone 3G. I suspect that we’re bound mostly by the read speed of the Pre’s Flash memory, but even then there’s no reason the Pre couldn’t be at least as fast as the iPhone. The more I tested the Pre the more I realized exactly how much time Apple spent optimizing the iPhone’s OS prior to its release.
Palm made a serious mistake when attempting to duplicate Apple’s success. The iPhone gained traction because it did not allow anything to compromise the user experience; applications and even web pages were quickly evicted from memory to preserve a very fast UI. Palm, with its significant hardware advantage, was not able to accomplish the same thing here.
Even when the iPhone gets slow, it’s still smooth. The Pre’s animations are not as smooth as Apple’s. Even when the Pre does something faster than the iPhone, it fails to do it as smoothly. It all comes down to a lack of optimization; Palm could easily fix these issues, but the Pre seems a tad premature. Compared to every other smartphone on the planet, Palm did an incredible job. Compared to Apple? There’s about 10% more polish needed in the animation department.
Web Page Rendering: The Pre Advantage
Where the Pre doesn’t fail to impress is in its web page rendering performance. First, let’s look at the raw bandwidth numbers:
|Apple iPhone 3G (3.0)||916 KB/s||3237 KB/s|
|Palm Pre||881 KB/s||3973 KB/s|
At my house Sprint’s EVDO and AT&T’s 3G network speeds were about the same. To test web page rendering performance however I visited several sites (full, not mobile versions), loading each one three times and taking the average time to load from the moment I entered the URL to the instant the progress indicator stopped animating.
|3G/EVDO||Apple iPhone 3G (3.0)||Palm Pre|
|anandtech.com||20.3 s||17.2 s|
|arstechnica.com||23.3 s||14.0 s|
|hothardware.com||38.9 s||20.8 s|
|pcper.com||43.2 s||42.8 s|
|digg.com||44.5 s||30.3 s|
|techreport.com||27.2 s||15.2 s|
|tomshardware.com||32.3 s||30.3 s|
|slashdot.org||33.5 s||23.8 s|
|facebook.com||37.1 s||36.0 s|
|Palm Pre Advantage||30% Faster|
On average, in my 3G vs. EVDO tests, the Palm Pre managed to render web pages around 30% faster than the iPhone 3G. My network bandwidth tests showed that I was getting relatively similar 3G and EVDO performance, so the rendering advantage is entirely due to the Pre’s faster processor. If anything, this is the sort of performance boost I would expect out of the iPhone 3GS when viewing web pages.
The network continues to be a large bottleneck however. Given the performance difference between the Cortex A8 and the ARM11, I would expect a larger difference in web page load speed - if we’re CPU bound at all. When I reviewed the first iPhone I surmised that we were quite CPU bound; moving to a faster internet connection (WiFi) should show an even larger gap between the Pre and the iPhone 3G if we were indeed CPU bound. Let’s see if I’m right:
|WiFi||Apple iPhone 3G (3.0)||Palm Pre||T-Mobile G1|
|anandtech.com||16.3 s||8.2 s||17.2 s|
|arstechnica.com||17.7 s||7.8 s||17.8 s|
|hothardware.com||35.2 s||11.2 s||24.4 s|
|pcper.com||33.3 s||18.0 s||34.0 s|
|digg.com||34.3 s||22.1 s||40.0 s|
|techreport.com||24.1 s||9.0 s||20.5 s|
|tomshardware.com||21.4 s||13.8 s||26.0 s|
|slashdot.org||26.0 s||20.9 s||46.0 s|
|facebook.com||31.7 s||19.6 s||37.7 s|
|Palm Pre Advantage vs iPhone 3G||83% Faster|
Remove some of the network bottleneck and the Pre stretches its legs; the gap now grows to 83%. Not only is the iPhone very CPU bound even while rendering web pages, it’s even more so on WiFi. For the WiFi results I also included the T-Mobile G1, which uses a 528MHz ARM11 processor (compared to the 412MHz ARM11 core in the iPhone 3G). The faster CPU isn't enough to really outperform the iPhone 3G, while it does pull ahead in some cases it isn't consistently faster. Apple needed to use the Cortex A8 to guarantee significant performance improvements in the 3GS.
Given that the iPhone 3GS is expected to use similar hardware to the Pre, this is the sort of performance improvement I would expect to see out of the new 3GS.
It’s Time for Multi-Core
Anyone who has owned an iPhone has experienced the stalling problem. Whether it’s switching between applications, clicking on a link or just trying to unlock your phone, occasionally the process will take much, much longer than expected. We’ve been spoiled by having multi-core processors everywhere since 2005, we haven’t forgotten the lessons behind why single-core is bad have we?
A single core microprocessor without SMT can only operate on a single thread of instructions at a time. Unfortunately for single core processors, we often have tens if not hundreds of threads contending for their attention. Thankfully these CPUs operate at millions if not billions of cycles per second and a good scheduler can cycle through many threads, hundreds of times per second.
If everything works ok, there’s nothing to worry about. All of your running threads each get a slice of time and cycle through until they’re complete. As with most things, the scheduling world doesn’t always work like that. Every now and then the scheduler will pick a thread to execute on the CPU that won’t relinquish its control, or the scheduler will screw up and keep picking the wrong thread for execution (e.g. a background task instead of a foreground task). In these situations you get what feels like a a frozen system.
The iPhone appears to handle these situations very well. The app will either take a long time to respond or it will simply crash and exit. Sometimes the phone will require a hardware reset to recover but most of the time it just behaves strangely for a bit.
The move to multiple cores helps alleviate this scenario by giving the OS a second core to schedule threads on. In the event that one core is busy and can’t handle a more immediate, at least to the end user, task the second core is there to help things remain smooth and responsive.
Luckily, ARM has just the solution - the Cortex A9. The Cortex A9 is an out-of-order ARM processor (the first of its kind) that supports multi-core configurations. The ARM11 actually supports multi-core configurations as well but I don’t expect many manufacturers to step back from the A8 to a multi-core ARM11 processor.
I’m expecting the multi-core A9 transition to happen in the next 12 months. If Apple is particularly ambitious (or feeling threatened), it could attempt to bring about app-level multitasking and multi-core at the same time next year.