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
Comments Locked

276 Comments

View All Comments

  • name99 - Wednesday, October 17, 2012 - link

    If you want to read non-technical reviews, there are a million other sites you can go to, from NYT and WSJ to Engadget and TheVerge.

    The WHOLE POINT of people reading Anand's reviews is to get tech details we don't get elsewhere.
    Perhaps as a followup you might want to suggest that John Siracusa in future limit his OSX reviews to a single letter-sized page?
  • rarson - Wednesday, October 17, 2012 - link

    No, it's not the "WHOLE POINT," the whole point is that reviews are reviews and tech articles are tech articles.
  • GotThumbs - Tuesday, October 16, 2012 - link

    "Those longing for an HTC One X or Galaxy S 3 sized device running iOS are out of luck. "

    I find it hard to believe there is even one person that is in this group. Apple's walled garden is mostly OS and portal based (Itunes).

    Especially with Apples maps being sub-standard.

    Please stick to facts.
  • A5 - Tuesday, October 16, 2012 - link

    If you don't want any editorial judgement or statements, there are plenty of places where you can just read a spec sheet and benchmark results.
  • Omophorus - Tuesday, October 16, 2012 - link

    I think the opposite is more likely... or at least I fall into that category.

    Mobile computing device aside, Android 4.0+ is shockingly much nicer to use (and this coming from a long time iPhone user) than iOS 5 or iOS6.

    If I could get the iPhone 5 handset, maybe with slightly better anodization, running Android 4.0+ I'd be in hog heaven.

    After playing with an iPhone 5, I really dig the hardware, but found the software woefully lacking.
  • crankerchick - Tuesday, October 16, 2012 - link

    I think you and the original commenter missed what the statement was saying. It said, "HTC One X or Galaxy S3 'sized' device..."

    Specifically, a larger screen iPhone, is where I think they were going with the statement, especially given the context of the paragraph where the statement was made.

    That said, I'm very much in the same camp as you. My number one device would be an iPhone-size and iPhone-build device running Android (but with a few tweaks since we are talking the ideal device). In fact, that is part of the reason I have an iPhone now and my Galaxy Nexus is sitting in a drawer by the bed--it's just too big and battery life is awful. I want a 4-4.2" 720p screen that doesn't have last year's hardware inside. The One S comes closest, but it's not on VZW to my knowledge, and it's still not "the best" hardware available, which you need with Android, especially on a manufacturer's skinned device.
  • perpetualdark - Monday, October 22, 2012 - link

    What about the Incredible 4g? I think this phone was overlooked because of it's proximity to the S3 release and the fact that the market is generally trending toward a nearly 5" display..

    I like this phone because it has the current generation of technology, is pretty darn thin, has a replaceable battery, has the 4" display (ie I am not holding a small tablet to my ear or carrying it in my pocket), and is, more importantly, android.

    Yes, the SLCD display may not be quite what the apple display is on paper, but to be perfectly honest, I have never noticed the differences.. Perhaps in a test environment, or to someone who calibrates displays all day, the Apple display would be better, I just don't see it.

    The s4 processor is not only fast, but plenty efficient, and the battery lasts easily 2 full days of heavy use. I can use it to read a kindle book for 6-8 hours over 2 days, talk a few hours, surf the web a few dozen times, text a few hundred texts, and even play games for an hour or two before I run out of battery. I have yet to go below 40% in one 24 hour period of time with the exception of using it with GPS and maps up.. the gps on 100% burns up the battery fast.

    gig of ram, 8 gigs on board storage, 32 more gigs with the sd card, etc, plenty of storage. 8 megapixal camera on back and a vga camera on front.
    ICS, LTE, Beats Audio, pretty much all the latest in tech..

    No, it can't quite compete with the S3, but it is pretty close to a One X in a 4" package and the closest thing to a One X you can get from Verizon, and honestly the phone that SHOULD be compared to the iphone5, given it is the only one with the current generation of hardware that is the same size. Sure, the iphone5 has an edge on the inc 4g in terms of tech specs, but when you add cost to the mix, the playing field is more level there as well, and to be honest, in real world applications the differences are going to amount to very small percentages.

    What people really want is a phone that fits their needs. Usually the most important things are screen size, OS preference, cost, and battery life. Performance is ONLY an issue when there is a problem with it.. Like when the iphone 4 dropped calls and couldn't do internet when you touched it.. The difference from the S4 to the A6 in real world application is a second or two in loading an app.. if even that.. most of my apps open instantly and with chrome and a good 4G connection I am betting that side by side loading web pages would be nearly identical. Specs are cool when comparing e-peen size but otherwise don't mean much in application.

    Not everyone is interested in big screens for a phone. Not everyone is interested in having a flexible OS. Not everyone is interested in the latest tech. Not everyone wants to spend a fortune on a phone that is, in practice, marginally better than what they have already. Not everyone is interested in bleeding edge technology. Sometimes you are looking for the phone that best suits YOUR needs. For me, that is an android platform, small form factor to fit in my front pocket comfortably as well as in my hand. A processor that was fast but power conservative. A battery that lasted a full day with reserve to spare, and could be used for 2 or 3 days if conserved well, AND could be swapped with a fully charged battery when travelling. I also like a phone that I can drop and scratch and not notice the dings and scratches.. since I put it in my pocket, I don't want to add a bulky case to keep it safe.. (I have dropped this phone dozens of times and 24" away you would never know it). I like to only pay $6.99 for insurance and be able to replace it if lost or stolen or broken for less than $100 ($12 per month for apple with $170 replacement deductible). And I like that I can use ANY micro-usb charger or cable to charge or connect to a computer. I don't have to buy any special adapters to make it work with my existing devices.

    Quite frankly, I think the difference between an android fan and an apple fan is that an android fan will not settle for the one device available to suit his needs, he will shop around to find the RIGHT one. If that happens to be an iphone, that is what he will get. But with dozens of models to choose from that are every bit as good if not better in every way that really matters, the chances of going with an iphone are pretty slim. An apple fan will settle for what is available and try to convince everyone around him that this one device will fit everyone's needs perfectly without exception.
  • crankerchick - Tuesday, October 16, 2012 - link

    I don't follow all the technicals like that, I'm more of an end user when it comes to mobile technology, but I think the trend towards the larger screens is more the MFRs pushing that a selling point (moar moar moar) to cover the fact that they can't fit the latest and greatest and cutting edge (NFC, quad core, LTE, etc) in the chassies of a 4" screen phone.

    Just my hunch. Wouldn't mind being schooled on this by someone in the know.
  • KPOM - Tuesday, October 16, 2012 - link

    I'd agree with that assessment. Apple was one of the last to move to 3G and one of the last to move to LTE because of battery life. The other manufacturers got around it by building thicker phones in the 3G era, and then with the LTE era started putting in bigger screens, which gave them room for bigger batteries (though the larger displays also required more power). It turned out enough people liked the bigger screens.

    Now that the power consumption levels are down, it will be interesting to see if others shrink their screens back down to Apple levels. The Galaxy SIII Mini is a half-hearted attempt, as it lacks LTE and has mediocre specs. But maybe someone else will take the bait.
  • rarson - Thursday, October 18, 2012 - link

    I feel like the iPhone 5 screen is actually too small (and I've heard complaints that the phone is too light, which I sort of agree with as well), but I think the Galaxy S3 is too big. I'm still using a Verizon Fascinate. It's got a bigger screen than the 5, but it's a bit smaller than the S2 and S3, perfect size. Thin but not too thin, and light but not too light. In fact, all I really want is a phone exactly like it, but with more power, better battery life, and maybe a slightly better screen (can't complain too much about the screen I already have).

    When I picked up the Fascinate, I knew it was the phone I wanted (helps that the price was only $50). When the S2 came out, I was excited to see it but disappointed by how much bigger the phone had gotten. I don't want a phone that I have to contort to get into my pocket. Apple's iPhone 5 is great in that respect, but after using this Fascinate for so long, its small size feels a bit cramped.

    I'd love to have the hardware of the Apple phone, but proprietary connectors and iOS are absolutely a no-go for me. I really don't care for iOS at all, because Android is so much easier to use.

Log in

Don't have an account? Sign up now