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
Custom Code to Understand a Custom Core
Section by Anand Shimpi
All Computer Engineers at NCSU had to take mandatory programming courses. Given that my dad is a Computer Science professor, I always had exposure to programming, but I never considered it my strong suit - perhaps me gravitating towards hardware was some passive rebellious thing. Either way I knew that in order to really understand Swift, I'd have to do some coding on my own. The only problem? I have zero experience writing Objective-C code for iOS, and not enough time to go through a crash course.
I had code that I wanted to time/execute in C, but I needed it ported to a format that I could easily run/monitor on an iPhone. I enlisted the help of a talented developer friend who graduated around the same time I did from NCSU, Nirdhar Khazanie. Nirdhar has been working on mobile development for years now, and he quickly made the garbled C code I wanted to run into something that executed beautifully on the iPhone. He gave me a framework where I could vary instructions as well as data set sizes, which made this next set of experiments possible. It's always helpful to know a good programmer.
So what did Nirdhar's app let me do? Let's start at the beginning. ARM's Cortex A9 has two independent integer ALUs, does Swift have more? To test this theory I created a loop of independent integer adds. The variables are all independent of one another, which should allow for some great instruction level parallelism. The code loops many times, which should make for some easily predictable branches. My code is hardly optimal but I did keep track of how many millions of adds were executed per second. I also reported how long each iteration of the loop took, on average.
| Integer Add Code | ||||||
| Apple A5 (2 x Cortex A9 @ 800MHz | Apple A5 Scaled (2 x Cortex A9 @ 1300MHz | Apple A6 (2 x Swift @ 1300MHz | Swift / A9 Perf Advantage @ 1300MHz | |||
| Integer Add Test | 207 MIPS | 336 MIPS | 369 MIPS | 9.8% | ||
| Integer Add Latency in Clocks | 23 clocks | 21 clocks | ||||
The code here should be fairly bound by the integer execution path. We're showing a 9.8% increase in performance. Average latency is improved slightly by 2 clocks, but we're not seeing the sort of ILP increase that would come from having a third ALU that can easily be populated. The slight improvement in performance here could be due to a number of things. A quick look at some of Apple's own documentation confirms what we've seen here: Swift has two integer ALUs and can issue 3 operations per cycle (implying a 3-wide decoder as well). I don't know if the third decoder is responsible for the slight gains in performance here or not.
What about floating point performance? ARM's Cortex A9 only has a single issue port for FP operations which seriously hampers FP performance. Here I modified the code from earlier to do a bunch of single and double precision FP multiplies:
| FP Add Code | ||||||
| Apple A5 (2 x Cortex A9 @ 800MHz | Apple A5 Scaled (2 x Cortex A9 @ 1300MHz | Apple A6 (2 x Swift @ 1300MHz | Swift / A9 Perf Advantage @ 1300MHz | |||
| FP Mul Test (single precision) | 94 MFLOPS | 153 MFLOPS | 143 MFLOPS | -7% | ||
| FP Mul Test (double precision) | 87 MFLOPS | 141 MFLOPS | 315 MFLOPS | 123% | ||
There's actually a slight regression in performance if we look at single precision FP multiply performance, likely due to the fact that performance wouldn't scale perfectly linearly from 800MHz to 1.3GHz. Notice what happens when we double up the size of our FP multiplies though, performance goes up on Swift but remains unchanged on the Cortex A9. Given the support for ARM's VFPv4 extensions, Apple likely has a second FP unit in Swift that can help with FMAs or to improve double precision FP performance. It's also possible that Swift is a 128-bit wide NEON machine and my DP test compiles down to NEON code which enjoys the benefits of a wider engine. I ran the same test with FP adds and didn't notice any changes to the data above.
Sanity Check with Linpack & Passmark
Section by Anand Shimpi
Not completely trusting my own code, I wanted some additional data points to help understand the Swift architecture. I first turned to the iOS port of Linpack and graphed FP performance vs. problem size:
Even though I ran the benchmark for hundreds of iterations at each data point, the curves didn't come out as smooth as I would've liked them to. Regardless there's a clear trend. Swift maintains a huge performance advantage, even at small problem sizes which supports the theory of having two ports to dedicated FP hardware. There's also a much smaller relative drop in performance when going out to main memory. If you do the math on the original unscaled 4S scores you get the following data:
| Linpack Throughput: Cycles per Operation | ||||
| Apple Swift @ 1300MHz (iPhone 5) | ARM Cortex A9 @ 800MHz (iPhone 4S) | |||
| ~300KB Problem Size | 1.45 cycles | 3.55 cycles | ||
| ~8MB Problem Size | 2.08 cycles | 6.75 cycles | ||
| Increase | 43% | 90% | ||
Swift is simply able to hide memory latency better than the Cortex A9. Concurrent FP/memory operations seem to do very well on Swift...
As the last sanity check I used Passmark, another general purpose iOS microbenchmark.
| Passmark CPU Performance | ||||||
| Apple A5 (2 x Cortex A9 @ 800MHz | Apple A5 Scaled (2 x Cortex A9 @ 1300MHz | Apple A6 (2 x Swift @ 1300MHz | Swift / A9 Perf Advantage @ 1300MHz | |||
| Integer | 257 | 418 | 614 | 47.0% | ||
| FP | 230 | 374 | 813 | 118% | ||
| Primality | 54 | 87 | 183 | 109% | ||
| String qsort | 1065 | 1730 | 2126 | 22.8% | ||
| Encryption | 38.1 | 61.9 | 93.5 | 51.0% | ||
| Compression | 1.18 | 1.92 | 2.26 | 17.9% | ||
The integer math test uses a large dataset and performs a number of add, subtract, multiply and divide operations on the values. The dataset measures 240KB per core, which is enough to stress the L2 cache of these processors. Note the 47% increase in performance over a scaled Cortex A9.
The FP test is identical to the integer test (including size) but it works on 32 and 64-bit floating point values. The performance increase here despite facing the same workload lends credibility to the theory that there are multiple FP pipelines in Swift.
The Primality benchmark is branch heavy and features a lot of FP math and compares. Once again we see huge scaling compared to the Cortex A9.
The qsort test features integer math and is very branch heavy. The memory footprint of the test is around 5MB, but the gains here aren't as large as we've seen elsewhere. It's possible that Swift features a much larger branch mispredict penalty than the A9.
The Encryption test works on a very small dataset that can easily fit in the L1 cache but is very heavy on the math. Performance scales very well here, almost mirroring the integer benchmark results.
Finally the compression test shows us the smallest gains once you take into account Swift's higher operating frequency. There's not much more to conclude here other than we won't always see greater than generational scaling from Swift over the previous Cortex A9.
Facebook
Twitter
RSS
276 Comments
View All Comments
Calista - Sunday, October 21, 2012 - link
English is not my native language (as I'm sure you have noticed) and so the flow in the language is far from flawless. But I still believe my opinions are valid and that the review was too long-winded.Teknobug - Wednesday, October 17, 2012 - link
I live in a big city and I don't know a single person that went and got the iPhone 5, most are happy with the iPhone 4 or whatever phone they're using, I don't see what's so great about the iPhone 5 other than it being built better than the iPhone 4's double sided glass structure (I've seen people drop their's on the train or sidewalk and it shattering on both sides!).And what now? iPad mini? I thought Apple wasn't interested in the 6-7" tablet market, Steve Jobs said 9" is small enough. I know Apple tried a 6" tablet a decade ago but the market wasn't read for it back then.
name99 - Wednesday, October 17, 2012 - link
You know what AnandTech REALLY needs now?A comment moderation system like Ars Technica, so that low-content comments and commenters (like the above) can be suppressed.
Teknobug is a PERFECT example of Ars' Troll Type #1: "Son of the "I don't even own a TV" guy: "
This is the poster who thinks other people will find it interesting that he cares nothing about their discussion or their interests, and in fact judges himself as somehow morally superior as a result. The morphology of this on Ars Technica includes people popping into threads about Windows 8 to proclaim how they will never use Windows, people popping into threads about iOS 6 to proclaim that they never have and never will buy an Apple product, and people popping into Android related threads and claiming that they will never purchase "crappy plastic phones." In these cases, the posters have failed to understand that no one really cares what their personal disposition is on something, if they have nothing to add to the discussion.
ratte - Wednesday, October 17, 2012 - link
yeah, my thoughts exactly.worldbfree4me - Wednesday, October 17, 2012 - link
I finished reading the review a few moments ago. Kudos again for a very thorough review, however I do a have a few questions and points that I would like to ask and make.Am I wrong to say, Great Job on Apple finally catching up to the Android Pack in terms of overall performance? The GS3, HTC X debuted about 6 months ago yes?
Have these benchmark scores from the competing phones been updated to reflect the latest OS updates from GOOG such as OS 4.1.X aka Jelly Bean?
Clearly the LG Optimus G is a preview of the Nexus 4,complete with a modern GPU In Adreno 320 and 2GB ram. I think based on history, the Nexus 4 will again serve as a foundation for all future Androids to follow. But again, good Job on Apple finally catching up to Android with the caveat being, iOS only has to push its performance to a 4inch screen akin to a 1080p LCD monitor verses a true gamers 1440p LCD Home PC setup. Ciao
Zinthar - Thursday, October 18, 2012 - link
Caught up and passed, actually (if you were actually reading the review). As far as graphics are concerned, no smartphone has yet to eclipse the 4S's 543MP2 other than, of course, the iPhone 5.I have no idea what you're going on about with the Adreno 320, because that only gets graphics performance up to about the level of the PowerVR SGX 543MP2. Please see Anand's preview: http://www.anandtech.com/show/6112/qualcomms-quadc...
yottabit - Wednesday, October 17, 2012 - link
Anand, as a Mech-E, I think somewhere the anodization facts in this article got very wonkyI didn't have time to read thoroughly but I saw something about the anodized layer equaling half the material thickness? The idea of having half a millimeter anodized is way off the mark
Typically there are two types of anodizing I use: regular, and "hard coat anodize" which is much more expensive
If the iPhone is scuffing then it's definitely using regular anodizing, and the thickness of that layer is likely much less than .001" or one thousandth of an inch. More on the order of a ten-thousandth of an inch, actually. The thickness of traditional anodizing is so negligible that in fact most engineers don't even need to compensate for it when designing parts.
Hard-coat anodize is a much more expensive process and can only result in a few darker colors, whereas normal anodizing has a pretty wide spectrum. Hard-coat thicknesses can be substantial, in the range of .001" to .003". This usually must be compensated for in the design process. Hard coat anodize results in a much flatter looking finish than typical anodize, and is also pretty much immune to scratches of any sort.
Aluminum oxide is actually a ceramic which is harder than steel. So having a sufficient thickness of anodize can pretty much guarantee it won't be scratched under normal operating conditions. However it's much cheaper and allows more colors to do a "regular" anodize
When I heard about scuffgate I immediately thought one solution would be to have a hardcoat anodize, but it would probably be cost prohibitive, and would alter the appearance significantly
guy007 - Wednesday, October 17, 2012 - link
A little late to the party with the review, the iPhone 6 is almost out now...jameskatt - Wednesday, October 17, 2012 - link
Anand is pessimistic about Apple's ability to keep creating its own CPUs every year. But realize that the top two smartphone manufacturers (Apple and Samsung) are CRUSHING the competition. And BOTH create their own CPUs.Apple has ALWAYS created custom chips for its computers - except for a few years when Steve Jobs accidentally let their chip engineers go when they switched to Intel and Intel's motherboard designs.
Apple SAVES a lot of money by designing its own chips because it doesn't have to pay the 3rd party profit on each chip.
Apple PREVENTS Samsung from spying on its chip designs and giving the data to its own chip division to add to its own designs. This is a HUGE win given Samsung's copycat mentality.
Apple can now always be a step ahead of the competition by designing its own chips. Realize that others will create copies of the ARM A15. But only Apple can greatly improve on the design. Apple, for example, greatly improved the memory subsystem on its own ARM chips. This is a huge weakness on otherARM chips. Apple can now custom design the power control as well - prolonging battery life even more. Etc. etc.
phillyry - Sunday, October 21, 2012 - link
Good points re: copycat and profit margin savings.I've always been baffled by the fact that Apple outsources their part manufacturing to the competition. I know that Samsung is a huge OEM player but they are stealing Apple's ideas. They are doing a very good job of it and now improving on those ideas and techs, which is good for the consumer but still seems completely illogical to me from Apple's perspective. Must be the 20/20 hindsight kicking in again.