Decoding Swift

Section by Anand Shimpi

Apple's A6 provided a unique challenge. Typically we learn about a new CPU through an architecture disclosure by its manufacturer, tons of testing on our part and circling back with the manufacturer to better understand our findings. With the A6 there was no chance Apple was going to give us a pretty block diagram or an ISSCC paper on its architecture. And on the benchmarking side, our capabilities there are frustratingly limited as there are almost no good smartphone benchmarks. Understanding the A6 however is key to understanding the iPhone 5, and it also gives us a lot of insight into where Apple may go from here. A review of the iPhone 5 without a deep investigation into the A6 just wasn't an option.

The first task was to know its name. There's the old fantasy that knowing something's name gives you power over it, and the reality that it's just cool to know a secret code name. A tip from a reader across the globe pointed us in the right direction (thanks R!). Working backwards through some other iOS 6 code on the iPhone 5 confirmed the name. Apple's first fully custom ARM CPU core is called Swift.

Next we needed to confirm clock speed. Swift's operating frequency would give us an idea of how much IPC has improved over the Cortex A9 architecture. Geekbench was updated after our original iPhone 5 performance preview to more accurately report clock speed (previously we had to get one thread running in the background then launch Geekbench to get a somewhat accurate frequency reading). At 1.3GHz, Swift clearly ran at a higher frequency than the 800MHz Cortex A9 in Apple's A5 but not nearly as high as solutions from Qualcomm, NVIDIA, Samsung or TI. Despite the only 62.5% increase in frequency, Apple was promising up to a 2x increase in performance. It's clear Swift would have to be more than just a clock bumped Cortex A9. Also, as Swift must remain relevant through the end of 2013 before the next iPhone comes out, it had to be somewhat competitive with Qualcomm's Krait and ARM's Cortex A15. Although Apple is often talked about as not being concerned with performance and specs, the truth couldn't be farther from it. Shipping a Cortex A9 based SoC in its flagship smartphone through the end of 2013 just wouldn't cut it. Similarly, none of the SoC vendors would have something A15-based ready in time for volume production in Q3 2012 which helped force Apple's hand in designing its own core.

With a codename and clock speed in our hands, we went about filling in the blanks.

Some great work on behalf of Chipworks gave us a look at the cores themselves, which Chipworks estimated to be around 50% larger than the Cortex A9 cores used in the A5.


Two Apple Swift CPU cores, photo courtesy Chipworks, annotations ours


Two ARM Cortex A9 cores , photo courtesy Chipworks, annotations ours

Looking at the die shots you see a much greater logic to cache ratio in Swift compared to ARM's Cortex A9. We know that L1/L2 cache sizes haven't changed (32KB/1MB, respectively) so it's everything else that has grown in size and complexity.

The first thing I wanted to understand was how much low level compute performance has changed. Thankfully we have a number of microbenchmarks available that show us just this. There are two variables that make comparisons to ARM's Cortex A9 difficult: Swift presumably has a new architecture, and it runs at a much higher clock speed than the Cortex A9 in Apple's A5 SoC. For the tables below you'll see me compare directly to the 800MHz Cortex A9 used in the iPhone 4S, as well as a hypothetical 1300MHz Cortex A9 (1300/800 * iPhone 4S result). The point here is to give me an indication of how much performance has improved if we take clock speed out of the equation. Granted the Cortex A9 won't see perfect scaling going from 800MHz to 1300MHz, however most of the benchmarks we're looking at here are small enough to fit in processor caches and should scale relatively well with frequency.

Our investigation begins with Geekbench 2, which ends up being a great tool for looking at low level math performance. The suite is broken up into integer, floating point and memory workloads. We'll start with the integer tests. I don't have access to Geekbench source but I did my best to map the benchmarks to the type of instructions and parts of the CPU core they'd be stressing in the descriptions below.

Geekbench 2
Integer Tests 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
Blowfish 10.7 MB/s 17.4 MB/s 23.4 MB/s 34.6%
Blowfish MT 20.7 MB/s 33.6 MB/s 45.6 MB/s 35.6%
Text Compression 1.21 MB/s 1.97 MB/s 2.79 MB/s 41.9%
Text Compression MP 2.28 MB/s 3.71 MB/s 5.19 MB/s 40.1%
Text Decompression 1.71 MB/s 2.78 MB/s 3.82 MB/s 37.5%
Text Decompression MP 2.84 MB/s 4.62 MB/s 5.88 MB/s 27.3%
Image Compression 3.32 Mpixels/s 5.40 Mpixels/s 7.31 Mpixels/s 35.5%
Image Compression MP 6.59 Mpixels/s 10.7 Mpixels/s 14.2 Mpixels/s 32.6%
Image Decompression 5.32 Mpixels/s 8.65 Mpixels/s 12.4 Mpixels/s 43.4%
Image Decompression MP 10.5 Mpixels/s 17.1 Mpixels/s 23.0 Mpixels/s 34.8%
LUA 215.4 Knodes/s 350.0 Knodes/s 455.0 Knodes/s 30.0%
LUA MP 425.6 Knodes/s 691.6 Knodes/s 887.0 Knodes/s 28.3%
Average - - - 37.2%

The Blowfish test is an encryption/decryption test that implements the Blowfish algorithm. The algorithm itself is fairly cache intensive and features a good amount of integer math and bitwise logical operations. Here we see the hypothetical 1.3GHz Cortex A9 would be outpaced by Swift by around 35%. In fact you'll see this similar ~30% increase in integer performance across the board.

The text compression/decompression tests use bzip2 to compress/decompress text files. As text files compress very well, these tests become great low level CPU benchmarks. The bzip2 front end does a lot of sorting, and is thus very branch as well as heavy on logical operations (integer ALUs used here). We don't know much about the size of the data set here but I think it's safe to assume that given the short run times we're not talking about compressing/decompressing all of the text in Wikipedia. It's safe to assume that these tests run mostly out of cache. Here we see a 38 - 40% advantage over a perfectly scaled Cortex A9. The MP text compression test shows the worst scaling out of the group at only 27.3% for Swift over a hypothetical 1.3GHz Cortex A9. It is entirely possible we're hitting some upper bound to simultaneous L2 cache accesses or some other memory limitation here.

The image compression/decompression tests are particularly useful as they just show JPEG compression/decompression performance, a very real world use case that's often seen in many applications (web browsing, photo viewer, etc...). The code here is once again very integer math heavy (adds, divs and muls), with some light branching. Performance gains in these tests, once again, span the 33 - 43% range compared to a perfectly scaled Cortex A9.

The final set of integer tests are scripted LUA benchmarks that find all of the prime numbers below 200,000. As with most primality tests, the LUA benchmarks here are heavy on adds/muls with a fair amount of branching. Performance gains are around 30% for the LUA tests.

On average, we see gains of around 37% over a hypothetical 1.3GHz Cortex A9. The Cortex A9 has two integer ALUs already, so it's possible (albeit unlikely) that Apple added a third integer ALU to see these gains. 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. If it's not more data being worked on in parallel, it's entirely possible that the data is simply getting to the execution units faster.

Let's keep digging.

MP

Geekbench 2
FP Tests 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
Mandlebrot 223 MFLOPS 362 MFLOPS 397 MFLOPS 9.6%
Mandlebrot MP 438 MFLOPS 712 MFLOPS 766 MFLOPS 7.6%
Dot Product 177 MFLOPS 288 MFLOPS 322 MFLOPS 12.0%
Dot Product MP 353 MFLOPS 574 MFLOPS 627 MFLOPS 9.3%
LU Decomposition 171 MFLOPS 278 MFLOPS 387 MFLOPS 39.3%
LU Decomposition MP 348 MFLOPS 566 MFLOPS 767 MFLOPS 35.6%
Primality 142 MFLOPS 231 MFLOPS 370 MFLOPS 60.3%
Primality MP 260 MFLOPS 423 MFLOPS 676 MFLOPS 60.0%
Sharpen Image 1.35 Mpixels/s 2.19 Mpixels/s 4.85 Mpixels/s 121%
Sharpen Image MP 2.67 Mpixels/s 4.34 Mpixels/s 9.28 Mpixels/s 114%
Blur Image 0.53 Mpixels/s 0.86 Mpixels/s 1.96 Mpixels/s 128%
Blur Image MP 1.06 Mpixels/s 1.72 Mpixels/s 3.78 Mpixels/s 119%
Average - - - 61.6%

The FP tests for Geekbench 2 provide some very interesting data. While we saw consistent gains of 30 - 40% over our hypothetical 1.3GHz Cortex A9, Swift behaves much more unpredictably here. Let's see if we can make sense of it.

The Mandlebrot benchmark simply renders iterations of the Mandlebrot set. Here there's a lot of floating point math (adds/muls) combined with a fair amount of branching as the algorithm determines whether or not values are contained within the Mandlebrot set. It's curious that we don't see huge performance scaling here. Obviously Swift is faster than the 800MHz Cortex A9 in Apple's A5, but if the A5 were clocked at the same 1.3GHz and scaled perfectly we only see a 9.6% increase in performance from the new architecture. The Cortex A9 only has a single issue port to its floating point hardware that's also shared by its load/store hardware - this data alone would normally indicate that nothing has changed here when it comes to Swift. That would be a bit premature though...

The Dot Product test is simple enough, it computes the dot product of two FP vectors. Once again there are a lot of FP adds and muls here as the dot product is calculated. Overall performance gains are similarly timid if we scale up the Cortex A9's performance: 9 - 12% increase at the same frequency doesn't sound like a whole lot for a brand new architecture.

The LU Decomposition tests factorize a 128 x 128 matrix into a product of two matrices. The sheer size of the source matrix guarantees that this test has to hit the 1MB L2 cache in both of the architectures that we're talking about. The math involved are once again FP adds/muls, but the big change here appears to be the size of the dataset. The performance scales up comparatively. The LU Decomposition tests show 35 - 40% gains over our hypothetical 1.3GHz Cortex A9.

The Primality benchmarks perform the first few iterations of the Lucas-Lehmar test on a specific Mersenne number to determine whether or not it's prime. The math here is very heavy on FP adds, multiplies and sqrt functions. The data set shouldn't be large enough to require trips out to main memory, but we're seeing scaling that's even better than what we saw in the LU Decomposition tests. The Cortex A9 only has a single port for FP operations, it's very possible that Apple has added a second here in Swift. Why we wouldn't see similar speedups in the Mandlebrot and Dot Product tests however could boil down to the particular instruction mix used in the Primarily benchmark. The Geekbench folks also don't specify whether we're looking at FP32 or FP64 values, which could also be handled at different performance levels by the Swift architecture vs. Cortex A9.

The next two tests show the biggest gains of the FP suite. Both the sharpen and blur tests apply a convolution filter to an image stored in memory. The application of the filter itself is a combination of matrix multiplies, adds, divides and branches. The size of the data set likely hits the data cache a good amount.

We still haven't gained too much at this point. Simple FP operations don't see a huge improvement in performance over a perfectly scaled Cortex A9, while some others show tremendous gains. There seems to be a correlation with memory accesses which makes sense given what we know about Swift's memory performance. Improved memory performance also lends some credibility to the earlier theory about why integer performance goes up by so much: data cache access latency could be significantly improved.

The A6 SoC Custom Code to Understand a Custom Core
Comments Locked

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

    +1
  • Klugfan - 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!

Log in

Don't have an account? Sign up now