CPU ST Performance: Faster & More Efficient

Starting off with this year’s review of the A15, in order to have a deeper look at the CPU single-threaded performance and power efficiency, we’re migrating over to SPEC CPU 2017. While 2006 has served us well over the years and is still important and valid, 2017 is now better understood in terms of its microarchitectural aspects in its components, and becoming more relevant as we moved our desktop side coverage to the new suite some time ago.

One continuing issue with SPEC CPU 2017 is the Fortran subtests; due to a lacking compiler infrastructure both on iOS and Android, we’re skipping these components entirely for mobile devices. What this means also, is that the total aggregate scores presented here are not comparable to the full suite scores on other platforms, denoted by the (C/C++) subscript in the score descriptions.

As always, because we’re running completely custom harnesses and not submitting the scores officially to SPEC, we have to denote the results as “estimates”, although we have high confidence in the accuracy.

In terms of compiler settings, we’re continuing to employ simple -Ofast flags without further changes, to be able to get the best cross-platform comparisons possible. On the iOS side of things, we’re running on the newest XCode 13 build tools, while on Android we’re running the NDKr23 build tools.

In terms of performance and efficiency details, we’re swapping the graphs around a bit from now on – on the left axis we have the performance scores of the tests – larger bars here mean better performance. On the right-side axis, growing from right to left are the energy consumption figures for the platforms, the smaller the figure, the more energy efficient (less energy consumed) a workload was completed. Alongside the energy figure in Joules, we’re also showcasing the average power figure in Watts.

Starting off with the performance figures of the A15, we’re seeing increases across the board, with absolute performance going up from a low of 2.5% to a peak of +37%.

The lowest performance increases were found in 505.mcf_r, a more memory latency sensitive workload; given the increased L2 latency as well as slightly higher DRAM latency, it doesn’t come too unexpected to see a more minor performance increase. However, when looking at the power and efficiency metrics of the same workload, we see the A15 use up almost 900mW less than the A14, with energy efficiency improving by +22%. 520.omnetpp_r saw the biggest individual increase at +37% performance – power here went up a bit, but energy efficiency is also up 24%.

The smallest performance gains of the A15 are found in the most back-end execution bound workloads, 525.x264_r and 538.imagick_r improve by only 8.7%, resulting in an IPC increase of 0.6% - essentially within the realm of measurement noise. Still, even here in this worst performance case, Apple still managed to improve energy efficiency by +13%, as the new chip is using less absolute power even though clock frequencies have gone up.

The most power demanding workload, 519.lbm_r, is extremely bandwidth hungry and stresses the DRAM the most in the suite, with the A15 chip here eating a whopping 6.9W of power. Still, energy efficiency is generationally slightly improved as performance goes up by 17.9% - based on first teardown reports, the A15 is still only powered by LPDDR4X-class memory, so these improvements must be due to the chip’s new memory subsystem and new SLC.

Shifting things over to the efficiency cores, I wanted to make comparisons not only to the A14’s E-cores, but also put the Apple chips in context to the competition, a Snapdragon 888 in this context, comparing against a 2.41GHz Cortex-A78 mid-core, as well as a 1.8GHz Cortex-A55 little core.

The A15’s E-cores are extremely impressive when it comes to performance. The minimum improvement varies from +8.4 in the 531.deepsjeng_r, essentially flat up with clocks, to up to again +46% in 520.omnetpp_r, putting more evidence into some sort of large effective sparse memory access parallelism improvement for the chip.  The core has a median performance improvement of +23%, resulting in a median IPC increase of +11.6%. The cores here don’t showcase the same energy efficiency improvement as the new A15’s performance cores, as energy consumption is mostly flat due to performance increases coming at a cost of power increases, which are still very much low.

Compared to the Snapdragon 888, there’s quite a stark juxtaposition. First of all, Apple’s E-cores, although not quite as powerful as a middle core on Android SoCs, is still quite respectable and does somewhat come close to at least view them in a similar performance class. The comparison against the little Cortex-A55 cores is more absurd though, as the A15’s E-core is 3.5x faster on average, yet only consuming 32% more power, so energy efficiency is 60% better. Even for the middle cores, if we possibly were to down-clock them to match the A15’s E-core’s performance, the energy efficiency is multiple factors off what Apple is achieving.


In the overview graph, I’m also changing things a bit, and moving to bubble charts to better spatially represent the performance to energy efficiency positioning, as well as the performance to power positioning. In the energy axis graphs, which I personally find to be more representative of the comparative efficiency and resulting battery life experiences of the SoCs, we see the various SoCs at their peak CPU performance states versus the total energy consumed to complete the workloads. On the power axis graphs, we see the same data, only plotted against average power. Generally, I find distinction of efficiency here to be quite harder between the various data-points, however some readers have requested this view. The bubble size corresponds to the average power of the various CPUs, we’re measuring system active power, meaning total device workload power minus idle power, to compensate components such as the display.

Apple A15 performance cores are extremely impressive here – usually increases in performance always come with some sort of deficit in efficiency, or at least flat efficiency. Apple here instead has managed to reduce power whilst increasing performance, meaning energy efficiency is improved by 17% on the peak performance states versus the A14. If we had been able to measure both SoCs at the same performance level, this efficiency advantage of the A15 would grow even larger. In our initial coverage of Apple’s announcement, we theorised that the company might possibly invested into energy efficiency rather than performance increases this year, and I’m glad to see that seemingly this is exactly what has happened, explaining some of the more conservative (at least for Apple) performance improvements.

On an adjacent note, with a score of 7.28 in the integer suite, Apple’s A15 P-core is on equal footing with AMD’s Zen3-based Ryzen 5950X with a score of 7.29, and ahead of M1 with a score of 6.66.

The A15’s efficiency cores are also massively impressive – at peak performance, efficiency is flat, but they’re also +28% faster. Again, if we would be able to compare both SoCs at the same performance level, the efficiency advantage of the A15’s E-cores would be very obvious. The much better performance of the E-cores also massively helps avoiding the P-cores, further improving energy efficiency of the SoC.

Compared to the competition, the A15 isn’t +50 faster as Apple claims, but rather +62% faster. While Apple’s larger cores are more power hungry, they’re still a lot more energy efficient. Granted, we are seeing a process node disparity in favour of Apple. The performance and efficiency of the A15 E-cores also put to shame the rest of the pack. The extremely competent performance of the 4 efficiency cores alongside the leading performance of the 2 big cores explain the significantly better multi-threaded performance than the 1+3+4 setups of the competition.

Overall, the new A15 CPUs are substantial improvements, even though that’s not immediately noticeable to some. The efficiency gains are likely key to the new vastly longer battery longevity of the iPhone 13 series phones – more on that in a dedicated piece in a few days, and in our full device review.

The Apple A15 SoC: Focus on Efficiency GPU Performance - Great GPU, So-So Thermals Designs
Comments Locked

204 Comments

View All Comments

  • name99 - Wednesday, October 6, 2021 - link

    v8 based.
    Essentially ARMv8.5 minus BTI.
  • name99 - Wednesday, October 6, 2021 - link

    https://community.arm.com/developer/ip-products/pr...
    lists what's new in 8.5

    Wiki still says A15 is essentially 8.4, but A14 is generally described as above, eg
    https://twitter.com/never_released/status/13610248...

    On the other hand, no-one has seen evidence of MTE usage in iOS (either iOS14 or 15). Which may reflect non-presence, or that compiler support isn't yet there?

    Mostly 8.5 is technical stuff that would be hard to test.
    One possibility would be the random number instructions. Maybe we'll get clarification of these over the next month?
  • name99 - Wednesday, October 6, 2021 - link

    We can see a little more detail here:
    https://github.com/llvm/llvm-project/blob/main/llv...

    We see that, among other things, A14 added
    - cache clean to deep persistence (basically instructions to support non-volatile-ram...)
    - security stuff to invalidate predictions
    - speculation barrier
    - and a few other (uninteresting to me) 8.5 security features

    Interestingly it also claims, on the performance side, to have added to A14 over A13, fusion of literal generation instructions, something I did not see when I tried to test for it -- presumably you have to get the order of the literal instructions correct, and I used the incorrect order in my quick tests?
    Along with claims of a number of other instruction fusion patterns that I want to test at some point!

    This was added in late Jan 2021, which suggests we won't see the equivalent for A15 until beginning of next year :-(
  • OreoCookie - Thursday, October 7, 2021 - link

    My understanding is that ARM v9 essentially mandates parts of the ARM v8.x ISA that were optional and introduces SVE2. If I read your posts correctly (thanks for doing the checking, much appreciated), then it seems that Apple has implemented the “first half” of ARM v9 anyway and the only notable omission is SVE2.

    SVE2 sure sounds like a nice-to-have, but like you wrote the compiler will play a crucial role here. I reckon a proper implementation will eat up quite a bit of die area, and if you are not going to use it, what is the point?
  • RoyceTrentRolls - Wednesday, October 6, 2021 - link

    Hear me out:

    A13 - 14 cycles 8MB 2 cores/big cluster
    M1 - 16 cycles 12MB 4 cores
    M1X/M2? - 18 cycles 16MB 8 cores

    🤪
  • name99 - Wednesday, October 6, 2021 - link

    It's a reasonable hypothesis BUT a big problem with cores sharing an L2 is that they all have to sit on the same frequency plane. (They can have different voltages, which matters if one of them is eg engaged in heavy NEON work, while another is doing light integer work; but they must share frequencies.)

    This may be considered less of a problem for the target machines?
    Alternatively you just accept that life ain't perfect and provide two clusters of 4core+(?12?16MB L2)?
  • OreoCookie - Thursday, October 7, 2021 - link

    With 2+4 core SoCs, I don’t think this is that big of an issue, though. Of course, it gets trickier once you scale up to more than 8 performance cores, but we will have to see what Apple’s solution is here anyway (8-core chiplets perhaps?).

    Overall, though, it seems that massively increasing caches is a common trend, AMD has been going in that direction (including their Zen 3 with additional cache slated for later this year) and IBM will be using massive caches on their new CPUs that will power their Z15 mainframes. The drawbacks are pretty clear, but the potential upside is, too.
  • mixmaxmix - Thursday, October 7, 2021 - link

    battery life test result please
  • mixmaxmix - Saturday, October 9, 2021 - link

    please
  • Raqia - Thursday, October 7, 2021 - link

    Die shot now available:

    https://semianalysis.com/apple-a15-die-shot-and-an...

    More caches all around, and the GPU doubles the number of FP32 ALUs without adding much die area.

Log in

Don't have an account? Sign up now