The A5 Architecture & CPU Performance

The original iPhone debuted with a single 412MHz ARM11 core built on a 90nm process. The 3G improved network performance in 2008 but left the SoC untouched. It wasn't until the iPhone 3GS in 2009 that the SoC got a major performance and power update. Apple moved to a 65nm process node, a brand new ARM Cortex A8 based SoC and an upgraded GPU. The A4 released in 2010 once again gave us a process shrink but kept the architecture unchanged.


Apple's A5 SoC

Apple's A5, first introduced with the iPad 2, keeps process technology the same while introducing a brand new CPU and GPU. The A5 integrates two ARM Cortex A9 cores onto a single die. The improvement over the A4 is tremendous. At the single core level, Apple shortened the integer pipeline without reducing clock speed. With a shorter pipeline the A5 gets more done per clock, and without decreasing clock speed the A5 inherently achieves better performance at the same clock. The move to the Cortex A9 also enables out-of-order instruction execution, further improving architectural efficiency. I've heard there's a 20% increase in performance per clock vs. the Cortex A8, but combine that with the fact that you get two A9s vs a single A8 in last year's design and you get a pretty big performance increase.

There are several situations where the A5's two cores deliver a tangible performance benefit over the A4's single core. Like Android, iOS appears to be pretty well threaded. Individual apps and tasks can take advantage of the second core without a recompile or version update. The most obvious example is web browsing.

Mobile Safari is well threaded. Javascript rendering can be parallelized as well as parts of the HTML parsing/rendering process. All of the major Javascript performance benchmarks show a 60 - 70% increase in performance over the A4, which is partially due to the availability of the second core:

SunSpider Javascript Benchmark 0.9.1 - Stock Browser

Rightware BrowserMark

This translates directly into faster page load times. As you can see in the video below, the iPhone 4S (left) loads the AnandTech front page over WiFi in about 5 seconds compared to 9 seconds on the iPhone 4 (right). That's really the best case scenario, the improvement in the next page load time was only about a second (7s vs 8s).

Typical improvements in load time fall in the 10 - 70% range, contributing significantly to the phone feeling snappier than its predecessor. To quantify the improvement I ran through our standard web page loading suite, a test that hits AnandTech, CNN, NYTimes, Engadget, Amazon, Digg and Reddit hosted locally on our lab's network. The average page load time over WiFi for all of the pages is below:

AnandTech Web Page Loading Performance Suite

While web page rendering is a natural fit for multiple cores, I was surprised by how poorly threaded some apps ended up being. For example, although I did see performance improvements in exporting edited videos from the iOS version of iMovie, the gains weren't always evident. A quick profile of the app revealed that much of the export process is still single threaded. Just as we've seen on the desktop, there will be some added work necessary to get all apps to utilize multiple cores on iOS.

It's not always performance within an app that saw improvement with the A5: application install and launch times are also much quicker on the 4S. The time to launch Epic's iOS Citadel demo went from 32 seconds on the iPhone 4 to 22 seconds on the 4S. While the iPhone 4 may feel fast enough for many users, the 4S is noticeably faster.

Photos App - Auto Enhance Image

Much of the faster feel comes from by shaving off of seconds here or there. For example, I noticed apps like Messages pop up just slightly quicker on the 4S and you'll see your listing of messages a hair faster than you would on the 4. In the video above you get a brief idea of the sort of subtle improvements I'm talking about. YouTube launches a fraction of a second quicker on the 4S vs the 4.

These subtle decreases in response time are simply icing on the cake. The move from a 4 to a 4S is one of those upgrades that you'll notice right off the bat but will really appreciate if you go back to an iPhone 4 and try to use it. If you do a lot of web browsing on your phone, you'll appreciate the 4S.

I wasn't entirely sure whether or not I could attribute all of these performance improvements to the faster CPU. It's possible that some of the tests I mentioned are IO bound and Apple could have used faster NAND in the 4S. To find out I rounded up a bunch of iPhone 4Ses at all available capacities and measured sequential write speed:

NAND Performance

Apple uses multiple sources for NAND so it's possible that you'll see these numbers move around a bit depending on your particular phone. It looks like the iPhone 4S' NAND is no faster than what Apple shipped last year - at least in sequential write speed. The target appears to be 20MB/s and Apple does its best to stay around there. My iPhone 4 is actually pretty quick at 22MB/s but the advantage isn't significant enough to make a huge deal about. I don't have a good way of measuring random IO performance yet but application launch time is largely governed by sequential IO so I don't expect we're seeing gains from anything outside of the CPU and memory bandwidth in the earlier tests.

Faster Throughput on WCDMA The Memory Interface
Comments Locked

199 Comments

View All Comments

  • Davabled - Monday, October 31, 2011 - link

    With Field test enabled, do numbers closer to zero indicate a better connection? (I'm referring to the numbers that replace the bars in the upper left corner)
  • Anand Lal Shimpi - Monday, October 31, 2011 - link

    Correct :)

    Take care,
    Anand
  • Formul - Monday, October 31, 2011 - link

    why the huge drop from iPad 2 to iPhone 4S in the GL benchmark pro? its only about 30% performance .... any explanation?
  • Anand Lal Shimpi - Monday, October 31, 2011 - link

    Because the number was incorrect :-P Fixed now :)

    Take care,
    Anand
  • ZebuluniteX - Monday, October 31, 2011 - link

    Great review as always Anand!

    In addition to the GL benchmark pro results Formul mentioned, I was also surprised to see the Motorola Droid RAZR for some reason do far better than other Gingerbread-based Android smartphones. It is listed as using different version of Android (2.3.5 vs 2.3.4 or older), but given that very similar results were shown between the iPhone 4S and Honeycomb-running Galaxy Tab 8.9 in your 'iPhone 4S Preliminary Benchmarks' article (where the 4S was a bit slower than the Galaxy Tab in SunSpider, and marginally faster in BrowserMark), I'm guess those are just mislabeled Galaxy Tab results. Is that the case?
  • Anand Lal Shimpi - Monday, October 31, 2011 - link

    Thank you - be sure to thank Brian Klug as well, he really did the bulk of the heavy lifting here. I just popped in to talk about silicon and battery life.

    The RAZR numbers are what we ran at the RAZR announcement: http://www.anandtech.com/show/4981/motorola-droid-...

    The improvement is likely due to an updated browser from Motorola. I included those numbers effectively as a placeholder until Ice Cream Sandwich arrives :)

    Take care,
    Anand
  • ZebuluniteX - Tuesday, November 1, 2011 - link

    Ah, thanks for the clarification, I missed that article. Hmm, that's interesting that, apparently, Motorola "ported" Honeycomb or Ice Cream Sandwich's browser optimizations to Gingerbread (or at least I assume that's what happened)...

    I'm in the market for a smartphone, and while I was leaning towards the 4S since I already am in the Apple ecosystem via an iPod Touch 2G, before pulling the trigger I wanted to read the Anandtech take on it. The review was excellent as always - thanks again to both you and Brian!
  • Formul - Monday, October 31, 2011 - link

    that was fast! i knew something was not right as there was no mention of this in the text :-)

    thanks for another great review, keep up the good work! :-)
  • zanon - Monday, October 31, 2011 - link

    The article wrote "The expectation that Apple will always deliver more than just a hardware upgrade is likely what made Siri a 4S exclusive."
    While only time will tell for sure, it seems quite possible that graduated ramp up had a bigger role to play here. As you say, most of the heavy duty lifting for Siri is going on server-side, and in turn local processing needs aren't too bad. However, the natural flip side of that of course is that the server-side infrastructure is required for the service to work at all, and resources aren't unlimited there either. Even with it limited purely to 4S users, Siri still had some availability problems in the first few days as millions activated and tried to user it simultaneously. It's not hard to imagine what would have happened if every single one of the tens of millions able to upgrade to iOS 5 *also* tried to start using it immediately. Apple has built a huge data center and that's all well and good, but nothing substitutes for actual working experience when it comes to massive software services.

    By limiting the initial rollout, Apple can do performance profiling, get an idea of average loads after initial "let's try it" dies down, and so forth. Staggering a rollout also means being able to plan for the general load rather then suffering the classic and well known double-bind of
    A) Building for a peak load, and ending up being left with a lot of extraneous hardware that barely gets used.
    B) Building for the average, then suffering from embarrassing and headline generating outages for a week or two.

    It's true they could just decide to keep it 4S only, but given they are still selling the iPhone 4, and probably make plenty of profit on that now very mature device, I think there is a decent chance they'll roll it out to a wider audience down the road.

    Also, a few typos:
    Page 2:
    I think the phrase is "pretty much par for the *course* for Apple..." rather then "par for the case".

    Pg 9, WiFi:
    "...newest WLAN, Bluetooth, and FM *cobo* chip" should I think be "combo".

    Pg 15:
    ...4S, without a (big blank, presumably some sentence was supposed to go here?)

    Pg 16:
    "aren't simply *academical*" should be "academic".

    Again, great review, thank you.
  • Anand Lal Shimpi - Monday, October 31, 2011 - link

    That's a very good point, I will add it to the discussion. The sinister view is to assume Apple did it to differentiate, the balanced view takes into account infrastructure, which is exactly what you did here :)

    And thanks for the corrections :)

Log in

Don't have an account? Sign up now