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.

Decoding Swift Apple's Swift: Visualized
POST A COMMENT

276 Comments

View All Comments

  • doobydoo - Friday, October 19, 2012 - link

    'Right, so if you have good vision, like I do, then at a foot away, you can see those pixels.'

    If you can see that then you would also be capable of observing that the SG3 doesn't have full pixels, it uses a PenTile display which overall has fewer sub pixels over a greater area than the iPhone 5 screen, making it both absolutely lower quality and relatively lower quality per area.
    Reply
  • KoolAidMan1 - Friday, October 19, 2012 - link

    You can discern individual pixels on an iPhone 5 display?

    Lies.
    Reply
  • dsumanik - Wednesday, October 17, 2012 - link

    Im sure this guy said the same thing when the 4 came out...3.5 was "big enough"

    Just watch when apple adds an even bigger screen he will be saying it is "perfect"

    The problem with iSheeps is that they need to get out there and actually use a different phone from a different ecosystem for a month, then switch back.

    Apple's devices are well built and tightly integrated, but there are serious shortcomings, drawbacks, and flaws that you will notice once you return to the platform.

    That said,

    Personally i purchase apple products due to the insanely high resale value, which allows me to keep up with new gear on a yearly basis for a reasonable price.

    Sent from my iphone 5
    Reply
  • khurtwilliams - Thursday, October 18, 2012 - link

    "iSheeps"? Must you resort to name calling to make your point? Reply
  • rarson - Thursday, October 18, 2012 - link

    "Personally i purchase apple products due to the insanely high resale value, which allows me to keep up with new gear on a yearly basis for a reasonable price."

    I don't see it. Maybe if you buy the newest thing as soon as it comes out and sell your old last-gen device that most people are still happy with, then you're selling it for a decent amount, but you're still spending way more money than any reasonable person would. There's absolutely no monetary argument to buy Apple products, because if money is your concern, then you shouldn't be buying them in the first place.

    Apple's phone prices are much closer in line with their hardware; for laptops and desktops, the resale value argument goes WAY out of whack.
    Reply
  • darwiniandude - Friday, October 19, 2012 - link

    I bought an early 2011 MBP last year for $2650 AUD. got a high res screen option etc. I heard rumours of the retina model and sold it just before the 12 months was up so the new purchaser still had a little warranty me could buy AppleCare if they wished. I sold it for $2300 AUD. This means I lost $350 over the year, it cost me $350 to have that machine for a year. I didn't buy AppleCare ($429 AUD) either.
    The retina model came out, and retailed for $2499 AUD

    I've been doing this since my first Mac, in 2006. I can't believe the crazy used prices on Macs especially if they are still current model and about a year old. I pay about $300-$400 a year to have the latest and greatest and a machine that is always in warranty. If I bought a cheap PC notebook for $400 I'd be suffering with an underpowered plastic machine with little ram, no SSD, and it might last more than a year but I wouldn't be happy with it anyway. Each to their own. I could never stay current with PCs because a year later the system was next to worthless, even if I'd put a $1000 video card in it at the time. (I now, reluctantly, game on consoles or a little in bootcamp)
    Reply
  • david22 - Thursday, October 18, 2012 - link

    "there are serious shortcomings, drawbacks, and flaws"

    So what are they?

    The problem with trolls is that they just spout bull.
    Reply
  • MobiusStrip - Friday, October 19, 2012 - link

    Apple refuses to pull its head out of its ass or LEARN. One profound impediment to making iOS devices useful is Apple's ridiculous fear, which you can see in its crippled SDK. One example: the lack of developer access to the dock port.

    But then there is just plain stupidity. There's no excuse for bullshit like this: http://goldmanosi.blogspot.com/2012/06/will-apple-...
    Reply
  • darwiniandude - Friday, October 19, 2012 - link

    Um, when someone calls me and I miss the call, iPhone shows a missed call. Then my carrier (Telstra) sends me a text message "You have a missed call from 0412xxxxxx" then "Please call 101 you have 1 new voicemail(s)"
    I get multiple alerts for both those SMS messages.
    Reply
  • rex251 - Sunday, October 21, 2012 - link

    Why going all the way in calling people that like apple products as sheeps?
    I think you should accept the fact that some people like small phones, and maybe like small smartphones, which neither iphone5 or sgs3 are.
    From my perspective iphone 4/4s screen was maximum I would go with something called phone into my pocket, but I do not, instead finding xperia mini great sized, although too thick.
    My point, why would we have to considere as progress only bigger screen phones as such, we do have plenty of tablets to pick from for that usage?
    Reply

Log in

Don't have an account? Sign up now