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
themossie - Tuesday, October 16, 2012 - link
The manufacturer's charger uses a set of pull-up resistors connected between the various USB lines, to indicate that the phone can pull maximum current. Unfortunately, every manufacturer (and sometimes different phones) use different resistances.See http://electronics.stackexchange.com/questions/144... for a brief writeup.
For what it's worth, I've only had this problem with iDevices and the HP Touchpad. I own circa-2011+ HTC, Motorola and Samsung phones, and they all work fine with every charger. My Droid 2 Global was my primary work phone until a few months ago, and works great with every charger. Not sure why your wife is having problems there.
crankerchick - Tuesday, October 16, 2012 - link
"The non-LTE phones see a sharp drop in battery life. At least at 28nm the slower air interfaces simply have to remain active (and drawing power) for longer, which results in measurably worse battery life. Again, the thing to be careful of here is there's usually a correlation between network speed and how aggressive you use the device. With a workload that scaled with network speed you might see closer numbers between 3G and 4G LTE."Perhaps you all could devise a test for this? Something like, change your LTE and 3G tests, where you decrease the time between page loads for the LTE test, to simulate doing more browsing since the pages load faster? One data point on this, with a reasonably selected change in page load duration, would be very helpful now that we have this very interesting dynamic clearly visible.
That said, as always, I appreciate the reviews presented here. Always thorough with lots of information to chew on beyond specs and "user opinion on user experience."
Just wish the reviews didn't take so long, but they are always worth it in the end.
TofDriver - Tuesday, October 16, 2012 - link
Thanks for this awesome article. Gigantic work, we'll worth the wait.I've learnt so much.
Would still appreciate it as an ebook, even after the web reading!
Seems like you're perfectionists who love to push limits... To me it does resonate with the team who designed the reviewed product.
name99 - Tuesday, October 16, 2012 - link
"Another potential explanation is that the 3-wide front end allowed for better utilization of the existing two ALUs, although it's also unlikely that we see better than perfect scaling simply due to the addition of an extra decoder."Remember the standard numbers. On this type of integer code:
1/6 instructions are branch
1/6 instructions are store
1/3 instructions are load
1/3 instructions are ALU
This means the usual first throttling point i cache access, if you can only do one load/store cycle.
If you limit your cache to one op/cycle, it's generally not worth going beyond 2-wide --- too often you're waiting on the cache.
Once you widen your cache (usually, at this stage, by allowing simultaneous read and write per cycle) three-wide makes sense.
Each cycle now (on ideal and some sort of "average" idealized code) you can now do some sort of combination of half a branch, 1.5 load/stores, and 1 ALU. Meaning that 2 ALUs (as long as they are not overloaded and also handling some aspect of the load/store) is enough for now.
[Of course things never work out quite this ideal --- you have burstiness in operation types, not to mention delays. But the compiler should try to schedule instructions to get this sort of average, and likewise the re-order queues will do what they can to shuffle things to this sort of average. 2ALUs helps with the bursts, 3ALUs is overkill.]
So I would say the primary important change made to go to three-wide in a way that is not a waste of time was to convert the L1 cache to dual-ported, supporting simultaneous load & store per cycle.
jiffylube1024 - Tuesday, October 16, 2012 - link
I have to commend the Anandtech team for the great review! It was a long wait, but well worth it. The info on anodizing, the "Swift" CPU @ 1.3 GHz, camera performance, etc. was worth waiting for. This article, in my eyes, is a culmination of the Anandtech team's knowledge in the tech industry - deconstructing A6 to figure out what it's made of, discussing Apple's manufacturing capabilities, etc. Very informative and well written!I am always amazed at how many complaints (and petty platform wars) get exposed on the comment board. I certainly appreciate them when an article is poorly written, contains false information or outright lies, but with an article like this, the comments section seems shy of the effusive praise it deserves!
------
On a slight tangent, I've enjoyed the first 8 Anandtech podcasts as well, and I have to say that I look forward to more non-iPhone related disucssion on future podcasts. The information was much appreciated, but for a tech site as broad as Anandtech, the first 8 podcasts have been VERY iPhone heavy in their content! Keep up the good work.
jamyryals - Thursday, October 18, 2012 - link
I think you're right, it has been iPhone heavy, but the start of the podcast kind of lined up with the launch/review process. Let's be honest, it is a huge selling high quality device and it's treated as such. I have a feeling Brian and Anand will have a lot to say about all of the impending Nexii/WP8 when they come out this quarter.krumme - Tuesday, October 16, 2012 - link
Good to see reviewers apreciation of low light capabilities for the BSI sensor, reflecting real world usage. Oposite to a lot of uninformed stupid reviews on the net.Its exactly the same practical difference between s2 and s3 cameras. Big difference for real usage.
All the mpix race must stop now. 8M is way to much for the quality anyway.
Zanegray - Tuesday, October 16, 2012 - link
I love the level of analysis and attention to detail. Keep it up!mrdude - Tuesday, October 16, 2012 - link
Wow, what an article. Really fantastic read. The lengths you guys have gone to in this review is stunning, frankly. Well done. Although I'm no Apple fanatic, I must say that this is one of the better articles I've read on AT :)Dennis Travis - Tuesday, October 16, 2012 - link
Totally outstanding review. You guys covered everything. Thanks so much!