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
TrackSmart - Wednesday, October 17, 2012 - link
Shouldn't the battery life on the Verizon Galaxy SIII with LTE be higher than shown? That result bunches up with the 3G scores rather than the LTE scores. I wonder if the "LTE" listing is a typo.It's also a bit surprising how much of a difference the connection speed makes (3G vs 4G LTE) for the battery life tests. Are you guys really testing differences in power efficiency under typical use? Or have you, inadvertently, created a strange test of air interface throughput/watt - which would vary based on signal strength and network speed, but not based on the main device power draw under typical browsing (i.e. screen + intermittent CPU usage spikes).
I would have guessed that that screen power draw would be the largest cause for differences between handsets, not the air interfaces on the new devices, now that LTE is no longer a power hog.
phillyry - Sunday, October 21, 2012 - link
If it's anything like the Telus GS3 up here in Canada than it's not likely a typo. My brother has it and it tanks so bad on LTE that he keeps it turned off. Same thing with NFC btw. Two major selling features of the GS3 that went down the tubes in reality.Skidmarks - Wednesday, October 17, 2012 - link
I've got to hand it to Apple, if nothing else they sure know to market their rubbish.Freakie - Wednesday, October 17, 2012 - link
I haven't seen the 5 in person, but every time I see a picture of the front of it, I swear its design echos Samsung devices quite a bit. If any light hits it directly then it looks off-black, at least in the pictures, to the point of looking like Samsung's Pebble Blue color back when it was a bit darker (Samsung Impression).They got rid of the band around the phone and just have a slanted surface which when looking at pictures taken 8 inches away from the phone, has it's sharp "edges" that it slants to become one smooth transition. Reminds me a lot of the GSII's front.
Now I'm not a fan of any design litigations going either way, but I've never seen a Samsung device echo the looks of Apple's devices quite as much as the iPhone 5 echos a number of Samsung's design flairs that they've been using for a while.
Just my two cents xP
kmmatney - Wednesday, October 17, 2012 - link
Are you kidding me. Look at how much the original; Samsung Galaxy copies the iPhone 3G. Same with the Galaxy SII.See for yourself
3G versus SGI
https://encrypted-tbn1.gstatic.com/images?q=tbn:AN...
and 4S versus SGII
http://www.gizmowatch.com/entry/comparing-mights-i...
medi01 - Wednesday, October 17, 2012 - link
Wow, SGII and 4S have the same screen ratio, you shameless iScum...Freakie - Wednesday, October 17, 2012 - link
Oh I never said that Samsung hasn't produced a phone similar to an iPhone, though your second picture is pretty ridiculous (that's the SGI not SGII) which came out several months before the 4. Not only that but the picture its self is most definitely shot/edited in a way to make them as similar as possible.My complaint is just Apple doing something very different than normal, and echoing someone else for a change. Usually they seem to go for something different than the rest and the iPhone 5 most definitely does not come anywhere near that.
steven75 - Wednesday, October 17, 2012 - link
This is probably the most silly comment I've read among any iPhone reviews. iPhones have always been similar overall since the revolution if 2007 and now you are seriously making the claim this looks more like a Samsung device?/smh
MNSoils - Wednesday, October 17, 2012 - link
Apple has an interesting story here and your group did a wonderful job telling it.On the 2 graph of the "Increased Dynamic Range" page, the idle power for the Tegra 3 SOC after finishing the Kraken benchmark seems awfully high for just the companion core. Does more time have to elapse before Android reverts to the companion core? Is the companion core not that power efficient (power-gated, etc.)? Does Android revert to the companion core?
colonelclaw - Wednesday, October 17, 2012 - link
Thanks for a terrific article. It's just a shame that about 75% of the comments will be by people who either love the device or hate it, and nothing in this carefully researched and written appraisal will make them change their minds either way.How did we get to this? Actually, don't answer, that would turn into an irrelevant pissing match too.