The A12 Tempest CPU µarch: A Fierce Small Core

Apple had first introduced a “small” CPU core alongside the Twister cores in the A10 SoC, powering the iPhone 7 generation. We’ve never really had the opportunity to dissect these cores, and over the years there was a bit of mystery around them as to what they’re capable of.

Apple’s introduction of a heterogeneous CPU topology in one sense was one of the biggest validations for Arm designs. Having separate low(er)-power CPUs on a SoC is a simple matter of physics: It’s just not possible to have bigger microarchitectures scale down power as efficiently as if you would just use a separate smaller block. Even in a mythical perfectly clock-gated microarchitecture, you would not be able to combat the static leakage present in bigger CPU cores, and thus this would come with the negative consequence of being part of the everyday power consumption on a device, even for small workloads. Power gating the big CPU cores, and instead shifting to much smaller CPU in contrast, helps alleviate static leakage, as well as (if designed as such) improving the dynamic leakage power efficiency.

The Tempest cores in the A12 are now the third iteration of this “small” microarchitecture, and since the A11 they are now fully heterogeneous and work independently of the big cores. But the question is, is this actually the third iteration, or did Apple do something more interesting?

The Tempest core is a 3-wide out-of-order microarchitecture: Already out of the gate this means it has very little to do with Arm’s own “little” cores, such as the A53 and A55, as these are simpler in-order designs.

The Tempest core’s execution pipelines are also relatively few: There are just two main pipelines that are capable of simple ALU operations; meanwhile one of them also does integer and FP multiplications, and the other is able to do FP additions. Essentially we just have two primary execution ports to each of the more complex pipelines behind them. Meanwhile in addition to the two main pipelines, there’s also a dedicated combined load/store port.

Now what is very interesting here is that this essentially looks identical to Apple’s Swift microarchitecture from Apple's A6 SoC. It’s not very hard to imagine that Apple would have recycled this design, ported it to 64-bit, and they now use it as a lean out-of-order machine serving as the lower power CPU core. If this is indeed Swift derived, then on top of the three execution ports described above, we should also find a dedicated port for integer and fp divisions, such as not to block the main pipelines whenever such an instruction is fed.

The Tempest cores clock up to a maximum of 1587MHz and are served by 32KB instruction and data caches, as well as an increased shared 2MB L2 cache that uses power management to partially power down SRAM banks.

In terms of power efficiency, the Tempest cores were essentially my prime candidate to try to get to some sort of apples-to-apples comparison between the A11 and A12 for power efficiency. I haven’t seen major differences in the cores besides the bigger L2, and Apple has also kept the frequencies similar. Unfortunately, "similar" isn't identical in this case; because the small cores on the A11 can boost up to 1694MHz when there’s only one thread active on them, I had no really good way to also measure performance at iso-frequency.

I did run SPEC at an equal 1587MHz frequency by simply having a second dummy thread spinning on another core while the main workloads were benchmarking. And I did try to get some power figures through this method by regression testing the impact of the dummy thread. However the power was near identical to the figures I measured at 1694MHz. As a result I dropped the idea, and we'll just have to just keep in mind that the A11’s Mistal cores were running 6.7% faster in the following benchmarks:

Much like on the Vortex big cores, the biggest improvements for the new Tempest cores are found in the memory-sensitive benchmarks. The benchmarks in which Tempest loses to Mistral are mainly execution bound, and because of the frequency disadvantage, there’s no surprise that the A12 lost in this particular single-threaded small core scenario.

Overall, besides the memory improvements, the new Tempest cores looks very similar in performance to last year’s Mistral cores. This is great as we can also investigate the power efficiency, and maybe learn something more concrete about the advantages of TSMC's 7nm manufacturing process.

Unfortunately, the energy efficiency improvements are somewhat inconclusive, and more so maybe disappointing. Looking at the SPECint2006 workloads overall, the Tempest-powered A12 was 35% more energy efficient than the Mistral-powered A11. Because the Mistral cores were running at a higher frequency in this test, the actual efficiency gains for A12 would likely be even less at an ISO-frequency level. Granted, we’re still looking at a general ISO-performance comparison here, as the memory improvements in A12 were able to push the Tempest cores to an integer suite score nearly identical to the higher-clocked Mistral cores.

In the overall FP benchmarks, Tempest was only 17% more efficient, even though it did perform better than the A11’s Mistral cores.

Putting the A11 and A12 small cores in comparison with their big brothers as well as the competition from Arm, there’s not much surprise in terms of the results. Compared to the big Apple cores, the small cores only offer a third to a fourth of the performance, but they also use less than half the energy.

What did surprise me a lot was seeing just how well Apple’s small cores compare to Arm’s Cortex-A73 under SPECint. Here Apple’s small cores almost match the performance of Arm’s high-performance cores from ust 2 years ago. In SPEC's integer workloads, A12 Tempest is nearly equivalent to a 2.1GHz A73.

However in the SPECfp workloads, the small cores aren’t competitive. Not having dedicated floating-point execution resources puts the cores at a disadvantage, though they still offer great energy efficiency.

Apple’s small cores in general are a lot more performant that one would think. I’ve gathered some incomplete SPEC numbers on Arm’s A55 (it takes ages!) and in general the performance difference here is 2-3x depending on the benchmark. In recent years I’ve felt that Arm’s little core performance range has become insufficient in many workloads, and this may also be why we’re going to see a lot more three-tiered SoCs (such as the Kirin 980) in the coming future. As it stands, the gap between the maximum performance of the little cores and the most efficient low performance point of the big continues to grow into one direction. All of which makes me wonder whether it’s still worth it to stay with an in-order microarchitecture for Arm's efficiency cores.

Neural Network Inferencing Performance on the A12

Another big, mysterious aspect of the new A12 was the SoC's new neural engine, which Apple advertises as designed in-house.  As you may have noticed in the die shot, it’s a quite big silicon block, very much equaling the two big Vortex CPU cores in size.

To my surprise, I found out that Master Lu’s AImark benchmark also supports iOS, and better still it uses Apple's CoreML framework to accelerate the same inference models as on Android. I ran the benchmark on the latest iPhone generations, as well as a few key Android devices.

鲁大师 / Master Lu - AImark - Inception V3 鲁大师 / Master Lu - AImark - ResNet34 鲁大师 / Master Lu - AImark - VGG16

Overall, Apple’s 8x performance claims weren’t quite confirmed in this particular test suite, but we see solid improvements of 4-6.5x. There’s one catch here in regards to the older iPhones: as you can see in the results, the A11-based iPhone X performs quite similarly to previous generation phones. What’s happening here is that Apple’s executing CoreML on the GPU. It seems to me that the NPU in the A11 might have never been exposed publicly via APIs.

The Huawei P20 Pro’s Kirin 970 falls roughly 2.5x behind the new A12 – which coincidentally exactly matches the advertised 2TOPs vs 5TOPs throughout capabilities of both SoC’s respective NPUs. Here the new Kirin 980 should be able to significantly close the gap.

Qualcomm’s Snapdragon 845 also performs very well, trading blows with the Kirin 970. AImark uses the SNPE framework for inference acceleration, as it doesn’t support the NNAPI as of yet. The Pixel 2 and Note9 offered terrible results here as they both had to fall back to CPU accelerated libraries.

In terms of power, I’m not too comfortable publishing power on the A12 because of how the workload was visibly transactional: The actual inferencing workload bumped up power consumption up to 5.5W, with lower gaps in-between. Without actually knowing what is happening in-between the bursts of activity, the average power figures for the whole test run can vary greatly. Nevertheless, the fact that Apple’s willing to go up to 5.5W means that they’re very much pushing the power envelope here and going for the highest burst performance. The GPU-accelerated iPhone’s power peaked in the 2.3W to 5W range depending on the inference model.

SPEC2006 Performance: Reaching Desktop Levels System Performance & iOS12 Improvements
POST A COMMENT

253 Comments

View All Comments

  • name99 - Saturday, October 6, 2018 - link

    If you're going to count like that, you need to throw in at least 7 Chinook cores (small 64-bit Apple-designed cores that act as controllers for various large blocks like the GPU or NPU).
    [A Chinook is a type of non-Vortex wind, just like a Zephyr, Tempest, or Mistral...]

    There's nothing that screams their existence on the die shots, but what little we know about them has been established by looking at the OS binaries for the new iPhones. Presumably if they really are minimal and require little to no L2 and smaller L1s (ie regular memory structures that are more easily visible), they could look like pretty much any of that vast sea of unexplained territory on the die.

    It's unclear what these do today apart from the obvious tasks like initialization and power tracking. (On the GPU it handles thread scheduling.)
    Even more interesting is what Apple's long term game here is? To move as much of the OS as possible off the main cores onto these auxiliary cores (and so the wheel of reincarnation spins back to System/360 Channel Controllers?) For example (in principle...) you could run the file system stack on the flash controller, or the network on a controller living near the radio basebands, and have the OS communicate with them at a much more abstract level.

    Does this make sense for power, performance, or security reasons? Not a clue! But in a world where transistors are cheap, I'm glad to see Apple slowly rethinking OS and system design decisions that were basically made in the early 1970s, and that we've stuck with ever since then regardless of tech changes.
    Reply
  • ex2bot - Sunday, October 7, 2018 - link

    Much appreciate the review! Reply
  • s.yu - Monday, October 8, 2018 - link

    Great job as always Andrei!
    I would only have hoped for a more thorough exploration of the limits of the portrait mode, to see if Apple really makes proper use of the depth map, taking a photo in portrait mode in a tunnel to see if the amount of blur is applied according to distance for example.
    Reply
  • Mic_whos_right - Tuesday, October 9, 2018 - link

    Thanks for this comment--Now I know why nothing last year. Great Anandtech standard of a review! Always above my intellect of understanding w/ info overload that teaches me a lot of the product. Reply
  • Moh Qadee - Thursday, November 1, 2018 - link

    Thank you for this great detailed review. I have been coming back to this review before making a purchase. Please make an comparison article of Iphone XS gaming vs other smartphones in market. How much does thermal make difference over longer periods before it starts to throttle or heat up. Would be able to give an approx time before you noticed heat while gaming on XS? I don't mind investing in an expensive phone as long as thermals doesn't limit the performance. There are phones like Razor 2 or Rog out. People make an comparison with an iPhone as it doesn't require much cooling. I wonder if gaming for above 20+ mins makes it challenging for Iphone to heat up enough that you should be worried about? Reply
  • Ahadjisavvas - Monday, November 19, 2018 - link

    And the exynos m3 had 12 execution ports right? Can you elaborate on the major differences between the design of the vortex core in the a12 and the meerkat core in the m3? I would deeply appreciate it if you could. Reply
  • Ahadjisavvas - Monday, November 19, 2018 - link

    And the exynos m3 has 12 execution ports right? Can you elaborate on the main differences between the design of the exynos m3 and the vortex core,that'll be really helpful and informative as well. Also,are you planning on writing a piece about the a12x soc, it'll be really interesting to hear how far apple has come with the soc on the 2018 ipad pro. Reply
  • alysdexia - Monday, May 13, 2019 - link

    "Now what is very interesting here is that this essentially looks identical to Apple’s Swift microarchitecture from Apple's A6 SoC."
    This comparison doesn't make sense and it seems like you took the same execution ports to determine whether the chips are identical, when the ports could be arbitrary for each release. Rather I took the specifications (feature size, revision) and dates of each from these pages: https://en.wikipedia.org/wiki/Comparison_of_ARMv7-... and https://en.wikipedia.org/wiki/Comparison_of_ARMv8-... to come up with these matches: Cortex-A15-A9 A6, Cortex-A15-A9 A6X, Cortex-A57-A53 A7, Cortex-A57-A53 A8, Cortex-A57-A53 A8X, Cortex-A57-A53 A9, Cortex-A57-A53 A9X, Cortex-A73 A10, Cortex-A73 A10X, Cortex-A75 A11, Cortex-A76 A12, Cortex-A76 A12X. For exemplum 5 execution ports could be gotten (I'm no computer engineer so this is a SWAG.) from the 3 in Cortex-A9 subtracted from the 8 in Cortex-A15 but the later big.LITTLEs with 9 and 5 ports could be split from 7 or 8 as (7+2)+(7−2) or (8+1)+(8−3). You need to correct the Anandtech and Wikipedia pages.

    faster -> swifter, swiftlier
    ISO -> iso -> idem
    's !-> they; 1 != 2
    great:small::big:lite::mickel:littel
    Reply
  • RSAUser - Friday, October 5, 2018 - link

    I still don't like iOS tendency towards warmer photos than it is irl. Reply
  • DERSS - Saturday, October 6, 2018 - link

    It is weird because it is warmer in bright light and bleaker in dim light.
    Why can not they just even it out, make the photos less yellowish in bright light and less bleak in dim light?
    Reply

Log in

Don't have an account? Sign up now