Apple's Swift: Pipeline Depth & Memory Latency

Section by Anand Shimpi

For the first time since the iPhone's introduction in 2007, Apple is shipping a smartphone with a CPU clock frequency greater than 1GHz. The Cortex A8 in the iPhone 3GS hit 600MHz, while the iPhone 4 took it to 800MHz. With the iPhone 4S, Apple chose to maintain the same 800MHz operating frequency as it moved to dual-Cortex A9s. Staying true to its namesake, Swift runs at a maximum frequency of 1.3GHz as implemented in the iPhone 5's A6 SoC. Note that it's quite likely the 4th generation iPad will implement an even higher clocked version (1.5GHz being an obvious target).

Clock speed alone doesn't tell us everything we need to know about performance. Deeper pipelines can easily boost clock speed but come with steep penalties for mispredicted branches. ARM's Cortex A8 featured a 13 stage pipeline, while the Cortex A9 moved down to only 8 stages while maintining similar clock speeds. Reducing pipeline depth without sacrificing clock speed contributed greatly to the Cortex A9's tangible increase in performance. The Cortex A15 moves to a fairly deep 15 stage pipeline, while Krait is a bit more conservative at 11 stages. Intel's Atom has the deepest pipeline (ironically enough) at 16 stages.

To find out where Swift falls in all of this I wrote two different codepaths. The first featured an easily predictable branch that should almost always be taken. The second codepath featured a fairly unpredictable branch. Branch predictors work by looking at branch history - branches with predictable history should be, well, easy to predict while the opposite is true for branches with a more varied past. This time I measured latency in clocks for the main code loop:

Branch Prediction Code
  Apple A3 (Cortex A8 @ 600MHz Apple A5 (2 x Cortex A9 @ 800MHz Apple A6 (2 x Swift @ 1300MHz
Easy Branch 14 clocks 9 clocks 12 clocks
Hard Branch 70 clocks 48 clocks 73 clocks

The hard branch involves more compares and some division (I'm basically branching on odd vs. even values of an incremented variable) so the loop takes much longer to execute, but note the dramatic increase in cycle count between the Cortex A9 and Swift/Cortex A8. If I'm understanding this data correctly it looks like the mispredict penalty for Swift is around 50% longer than for ARM's Cortex A9, and very close to the Cortex A8. Based on this data I would peg Swift's pipeline depth at around 12 stages, very similar to Qualcomm's Krait and just shy of ARM's Cortex A8.

Note that despite the significant increase in pipeline depth Apple appears to have been able to keep IPC, at worst, constant (remember back to our scaled Geekbench scores - Swift never lost to a 1.3GHz Cortex A9). The obvious explanation there is a significant improvement in branch prediction accuracy, which any good chip designer would focus on when increasing pipeline depth like this. Very good work on Apple's part.

The remaining aspect of Swift that we have yet to quantify is memory latency. From our iPhone 5 performance preview we already know there's a tremendous increase in memory bandwidth to the CPU cores, but as the external memory interface remains at 64-bits wide all of the changes must be internal to the cache and memory controllers. I went back to Nirdhar's iOS test vehicle and wrote some new code, this time to access a large data array whose size I could vary. I created an array of a finite size and added numbers stored in the array. I increased the array size and measured the relationship between array size and code latency. With enough data points I should get a good idea of cache and memory latency for Swift compared to Apple's implementation of the Cortex A8 and A9.

At relatively small data structure sizes Swift appears to be a bit quicker than the Cortex A8/A9, but there's near convergence around 4 - 16KB. Take a look at what happens once we grow beyond the 32KB L1 data cache of these chips. Swift manages around half the latency for running this code as the Cortex A9 (the Cortex A8 has a 256KB L2 cache so its latency shoots up much sooner). Even at very large array sizes Swift's latency is improved substantially. Note that this data is substantiated by all of the other iOS memory benchmarks we've seen. A quick look at Geekbench's memory and stream tests show huge improvements in bandwidth utilization:

Couple the dedicated load/store port with a much lower latency memory subsystem and you get 2.5 - 3.2x the memory performance of the iPhone 4S. It's the changes to the memory subsystem that really enable Swift's performance.

 

Apple's Swift: Visualized Six Generations of iPhones: Performance Compared
Comments Locked

276 Comments

View All Comments

  • KPOM - Wednesday, October 17, 2012 - link

    However, Apple made a point about anodizing in its display. Also, Apple has historically placed a premium value on industrial design so it is interesting to read more specifics. What has struck me about Apple is how much time they devote to things people don't notice consciously or will never see on a spec sheet, but which can unconsciously affect the user experience. The aluminum has a nice feel to it, and I can see why Apple would forgo putting a resin coating on it, even though it would make it less susceptible to scratching. Understanding the physics helps make clear what kind of compromises Apple needs to make.
  • phillyry - Sunday, October 21, 2012 - link

    As per emotional input:

    I actually look for this in the review and podcasts because it colours the facts.

    While I find the facts to be interesting and a good way to pass the time, at the end of the day my purchase decision, like those of human beings in general, will be largely guided by the sentiment of the matter.

    People want to know how happy others are with their devices. Just facts alone lack humanity. I personally love hearing opinions, side comments and anecdotes that give me insight into the thoughts, feelings and experiences of people who's opinions I hold in high regard, such as anand and the gang.

    There's something to be said for the qualitative experience that comes with the daily use of the device as your primary 'phone'.

    Many others may also be looking to hear the comradery, jest, and fun-casual tone that you can get on this site when these guys just let their opinions out or go off on technical tangents. If you listen to the podcasts it'll all make more sense.
  • phillyry - Sunday, October 21, 2012 - link

    P.S. the feeling that someone else, like anand, has about the device is also important because, if you are considering buying one of these things than you're going to have it for a couple of years and won't want to feel stuck with it.
  • Spunjji - Friday, October 19, 2012 - link

    I have to agree here... I already know how anodizing works (not specialist knowledge, we were taught in high-school...) and even if I didn't, I'm not sure a 'phone review is the best place to learn. An outside link would have sufficed. The whole thing does basically say that Apple had no choice in the matter unless they change the design, and that's really the point there. They should have changed the bloody design.
  • arghhh - Tuesday, October 16, 2012 - link

    How is it as a phone? Iphone never has been good at its primary function (I take an old clamshell over most smartphones in that regard).
  • Arbee - Tuesday, October 16, 2012 - link

    Brian Klug covered voice quality in this writeup, and AT's previous iOS 6 review covered the new voice call features. The upshot is it's at least as good as any other smartphone, even if no cellphone can replace a hardwired slab of mid-60s AT&T bakelite :)
  • manik. - Tuesday, October 16, 2012 - link

    Awesome read.
  • Tangey - Tuesday, October 16, 2012 - link

    The gpu comparison table shows the new iPad running @200mhz, it actually runs @250mhz ( as did the gpu in the ipad2). In a previous article you used this incorrect 200mhz as a reference point to determine that the iphone5 was running its gpu @266mhz.

    My calculations based on the iphone5's performance relative to the ipad3 @ 250mhz, indicate to me that the 543mp3 in the iphone5 is running in excess of 300mhz, most likely 325mhz, which also happens to be an exact divider of the 1.3ghz clock of the CPUs.
  • DustoMan - Tuesday, October 16, 2012 - link

    Have you ever looked into why phones from certain manufactures are so picky about their chargers? I've had phones from HTC, Motorola, and Samsung and I've had three wildly different experiences when it comes to what chargers will work in what devices. When I had an HTC Incredible, I could stick pretty much anything I wanted to it and it would charge. If the charger didn't have much current, it would charge slower than a charger with my current. My Galaxy Nexus would work with a few of my chargers, but the oddest thing would happen when I would try connecting it to a Griffin car adapter that had the 1.5A plug necessary to charge a first gen iPad. The only plug that would charge it consistently was a car adapter that I purchased that was branded Samsung. Even an adapter that Verizon sold me as being compatible wouldn't work. Finally the worst offender is my wife's Droid 2 Global. It will only charge with a Motorola adapter. Adapters that work with my Galaxy Nexus, which you would think would need chargers with a higher current, wouldn't work. To charge her phone on my PowerMat, I have to plug the phone into a reserve battery and then use the Powermat to charge that reserve battery while it's charging her phone. Stupid huh?
  • zephxiii - Tuesday, October 16, 2012 - link

    Yes i recall Motorola's earlier microUSB equipped phones to be very picky....especially if the battery went completely flat as it seemed like only Motorola chargers (or compatible) would breathe life back into them.

Log in

Don't have an account? Sign up now