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
darwinosx - Tuesday, October 16, 2012 - link
The iPhone 5 display is better than any current Android display.But Motorola and Android if you want a company that is dying and being sold and a copycat cheap phone with no service and support.
V-Money - Tuesday, October 16, 2012 - link
Your wisdom and informative argument adds tremendous value to this post. For the record though, the OP said specifically battery life and 720p display, so the response was relevant.The rest of your post is petty, get over yourself. If you are going to play the copycat card you should have done it before Apple decided to go with a bigger screen and use a (eerily similar) notification bar to what Android phones have had for years.
As for quality (of display or otherwise), that is subjective analysis and considering that Apple only releases one phone at a time and Android manufacturers many, its a stupid argument for anyone to make. Case and point, I can find many android phones that are much more terrible than the iPhone, but I can also find many that are better. The iPhone is a decent phone, but its not for everyone. Every consumer has their preference.
My point being there is not one-size-fits-all phone, so quit acting high and mighty with your close mindedness. You are not better than those around you because you bought into Apple's marketing, you are just a fool dealing with the first world problem of living such a meaningless existence that you have to hold on to the imaginary power an inanimate object pretends to give to you.
Alucard291 - Tuesday, October 16, 2012 - link
I feel that your argument may be too good for him to reply to :)He seems awfully angry :D
crankerchick - Tuesday, October 16, 2012 - link
Great reply. If there's one place I just want to exchange comments without playing the "my toy is better than yours" game, it's here on AnandTech.Gradly - Wednesday, October 17, 2012 - link
I'm sick of ppl comparing iPhone to other devices. I'm sick of those telling you iPhone borrowed the notifications slider form android and skipping the myriad of things that other borrowed form iPhone. Apple has always said that "we are not the first but we do it the best". I'm sick of those who still don't realize that before iPhone ppl were living in caves actually.I'm an Apple lover not an Apple fanboy. I just adore the design, aesthetics, and GUI of Apple devices.
Penti - Wednesday, October 17, 2012 - link
It's sadly Apple that goes and patent UI-elements to use against their competitors that is why it's always brought up. It would be totally unnecessary otherwise. You might look at who's the inspiration otherwise and it's often not Apple. In reality we had capacitive touch screens (it's not Apples tech of course) before, app store before, Android even had an SDK out before Apple. Competitors like Symbian/Nokia, HP WebOS, and Blackberry are even allowed to use stuff like bounce back effect even without (or before) any agreement with Apple. They should have credit but they didn't all the sudden bring out their device with what we now call smartphone features, it lacked most functions at first and slowly iterated, it did a lot poorer in many areas then it's competitors was doing even before iPhone and the first few years it also showed in sales numbers which were not high at the first 2-3 years. It did show us how important a good platform was. Guys like Rubin had already figured that out though. So I'm not sure what they would borrow. Full WebKit-browsers on mobile is a good example of stuff they are co-developing but it was out in Nokia devices in 2006, netfront and Opera was never good alternatives to build into your platform. Stock Android don't have the bounce back effect, UI's looking like Apples and so on. Not even TouchWiz on Samsung's tablets looks like or infringes anything (design-wise) by Apple. They clearly have their own ideas. They are not the "me too", others might try to emulate them more in a business sense though. But they will be punished by the market by their execution instead of by Apple. It's not like any of the major players are fruit ninja-clones though.iPhone was desperately rudimentary at first. It didn't do applications and the web, messaging, photos etc better then anybody. What they did good was to iterate and improve. They take enterprise / corporate customers more seriously then Microsoft and so on in this field. Even if it took some time for them to get there. So they do plenty of good. It's a good platform, but it's not like they gave their competitors their blueprints for their devices / os of today back in 2007 and both have made many improvements. Well maybe not Microsoft but it takes a few years to start over. Apple has even got into hardware (components) a bit. Commoditization and convergence has reached far beyond the mobile field. That's great even if Apple won't enter them. Still don't know why any competitor would like to turn themselves into a retail giant and employ mostly store staff as Apple does – Microsoft should start doing what they are good at instead. Google would be the most evil company in the world if they had started to patent and sue based on UI-features and methods. Or if they really tried to stop Bing and Bing Maps (and getting it banned in some markets) for example. It doesn't really matter who was first and who invented what if you take it to court were that doesn't really count and that creates a lot of BS surrounding the whole issue and companies involved that is largely unnecessary. But the real silly thing is why they fight. It's not based on IPR, it's basically that they want to be alone in doing whatever, even if they can't really make that claim to have sole rights to something. But ultimately courts do get that under control even when corporate leaders turn to fighting outside of releasing product.
slickr - Tuesday, October 16, 2012 - link
LOL. Don't make me laugh. It has still the worst display and has had the worst display for at least 3 years.A5 - Tuesday, October 16, 2012 - link
Your response is just as dumb as his. The iPhones have excellent displays.medi01 - Wednesday, October 17, 2012 - link
None of the iPhones have anything to compare with AMOLEDs, on top of having idiotic resolution.On tablet space, only iPad 3 matched color gamut of THE FIRST Samsung Galaxy Tab.
thunng8 - Wednesday, October 17, 2012 - link
How does 67.5% of sRGB on the galaxy tab 10.1 match the 94.4% on the ipad 3?http://www.anandtech.com/show/5688/apple-ipad-2012...