The iPhone 5 Review
by Anand Lal Shimpi, Brian Klug & Vivek Gowri on October 16, 2012 11:33 AM EST- Posted in
- Smartphones
- Apple
- Mobile
- iPhone 5
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.
Facebook
Twitter
RSS
276 Comments
View All Comments
mykebrian - Thursday, October 18, 2012 - link
is motorola razr i same price with iphone 5?Death666Angel - Thursday, October 18, 2012 - link
"By controlling its own SoC destiny it could achieve a level of vertical integration that no OEM has enjoyed in recent history."I would argue that Samsung enjoys a similar level of vertical integration. They trade the OS-stuff for some fabs. Not sure which can be more profitable. But other than that, they are very much like Apple in terms of vertical smartphone integration I think. :)
iwod - Thursday, October 18, 2012 - link
Any Reason Why Front Camera not using High Profile When Recording Video? It could have saved yet another bit of space with MUCH better quality then baseline.And do Apple offically support play back of H.264 High Profile Video Clip yet?
Spunjji - Friday, October 19, 2012 - link
I very much appreciated the details on the SoC design. Your attempts to refine your battery life analysis were also appreciated, as these do seem to better reflect real-world usage. In general this article was well-researched, well-written and very informative.Unfortunately, the section on the anodization process does end up reading like one big apology. The matter is explained in detail but it's done with an air of resignation, as if this were the only option available to Apple. The fact is that they could have retained some additional girth (whilst still losing some) and had a device with good handling, good aesthetics and superior durability. No comparison to competing devices is made whatsoever, so we have no idea based on your article alone if this really is unavoidable or just poor choice of materials.
The same goes for the part about the camera flare. Is a short comparison with a few relevant models too much to ask? The problem is that (like the previous criticism) I already know how this comes out and it doesn't look very good for Apple.
So there are hundreds of hours spent testing comparative performance and battery life where Apple win, yet no time at all dedicated to comparative analysis where they do not look so good. That starts to look upsettingly like bias. I hope that isn't the case but based on other areas (notebook reviews in particular) it starts to feel like a theme.
Anandtech, as a site I love your tech journalism, but the personal preferences of the writers need to stay at home (or firmly in editorials).
Slaanesh - Friday, October 19, 2012 - link
Couldn't agree more.Krysto - Friday, October 19, 2012 - link
I have to agree. Through out the article, you almost got the impression of worship from the writers, and they've only focused on what Apple did right and how much better that was than their competitors.And what's with all the going back to history of Apple's devices? Was that really necessary for a phone review? Should we expect this for all new iPhones...or for all new Galaxy S devices? I think that part alone shows bias.
And was 50 page review (or whatever it is) really necessary and to wait a month and a half after the product launch? The reason I'm asking is because I know they will never repeat this for any other non-Apple product. But I also think it's kind of pointless, and reviews need to appear max 1 week after the product launches. Maybe two. More than that is really pointless, and it's already obvious in the review that half of it is about how awesome Apple were in the past and still are, and only the other half goes down to the analysis.
dyc4ha - Saturday, October 20, 2012 - link
+1Klugfan - Friday, October 19, 2012 - link
Does everyone remember Edward Tufte's complaints about the iPhone 4 design?If I wasn't concerned about impact on the antenna performance, I'd be tempted to take some fine grit sandpaper to my black iPhone 5, and round off the edges a little. Believe it.
If your biggest concern about phones _really_ is resale value, well the iPhone 5 will do fine, with or without scuffs. If your biggest concern about brain phones is what they look like to other people who see you using them, well, first you're an idiot, and second the iPhone 5 really will do fine there, with or without scuffs.
Does my phone make me look smug? Whatever shall I do.
Hxx - Friday, October 19, 2012 - link
got this phone close to release day and I'm throughly impressed with it. Coming from a droid incredible 2 who crapped out on me 10 months after purchase (the memory slot broke and lost all my pics, videos etc - not fun) I gotta say this is my first interaction with an iOS powered device and so far i love it. I think most Apple products are overpriced (hence the reason why i never got one) but this phone is a beauty for $199 given that i paid almost just as much 1 year ago for my droid phone. A huge thank you to Anandtech for providing such detailed review. Although i may never need as much detail about a phone :-), its nice to know i can always rely on you guys if I ever have any technical questions.Good job Guys!
ol1bit - Friday, October 19, 2012 - link
As always, Anandtech gets into the details I didn't even know I wanted to read about!I'm not an apple product owner, and never plan to be, but it really appears to be a great phone.
Keep up the good work!