Performance, Power, Area (PPA)

In terms of performance ARM claims it will exceed the A72 in all important metrics relevant to mobile workloads. Examples were scarce but on workloads such as BBench (Website loading benchmark) the A73 is claimed to be up to 10% better performance than the A72 – on the same process and frequency. SIMD/NEON (FFMEG Codec) workloads are supposed to improve by up to 5%, mostly a side-effect from the better memory subsystem. Memory sees the largest gains with up to 15% improvement (JMC Stream Copy 64b).

I asked what we should be expecting in terms of performance degradations and of course the biggest disadvantage will be in micro-benchmarks such as Dhrystone. ARM promises SPEC performance will be the same as on the A72 it’s likely that the downgrade from a 3-wide decoder to a 2-wide one won’t affect many relevant workloads. I saw the same behaviour reflected in the A17 versus the A15 comparison as the former was more than able to keep up with the larger microarchitecture in almost all of the workloads and benchmarks I threw at it, so I have little doubt that the A73 will be able show similar behaviour against the A72.

More importantly it’s power consumption which sees the largest improvements. We see up to 25% power reduction in integer workloads and up to ~30% in floating point and L2 cache memory operations. ARM publishes that the A73 uses at least 20% less power than the A72 at the same process and frequency.

An important addition to power efficiency is the inclusion of hardware-governed retention states. This feature was first introduced in the Cortex A35 late last year and now sees adoption in the A73 microarchitecture. Retention is a microarchitectural clock-gating state that was available for a while now, however it was still software controlled, meaning it still had fairly low granularity and most vendors never chose to implement or expose it to current devices as they preferred to fall back to WFI clock gating and power gating. The addition of a hardware governor greatly improves the capabilities of the retention state power management and ARM says that it can bring very significant reductions in dynamic power consumption.

The A73 is up to 25% smaller than the A72 when implemented on the same process with the same performance targets. The A72 is already getting quite small on new process nodes so the A73 will seem quite tiny on future nodes such as 10nm. 

Where the die size reduction will have the biggest impact however is on the mid-range. A 2-core Artemis cluster is supposed to be as big as a 4-core A53 cluster. We’ve seen a lot of 4+4 A53 implementation from various vendors and frankly the performance was not all that convincing as even high-clocked A53’s lagged a lot behind SoCs implementing big high-performance microarchitectures. It’s only been recently with the Snapdragon 650 and 652 that we’ve finally see performance of the mid-range catch up to that of more expensive flagships. ARM makes a point for replacing these 4+4 A53 SoCs with 2+4 A73+A53 SoCs as they’re able to keep the same area footprint (which in terms means same cost for the vendors) while vastly improving single-thread performance.

While vendors will certainly be able to use the A73 on older process nodes such as 28nm, ARM talked more about future nodes such as 10nm. Here again we see ARM aiming for low power and sustained performance and says we’ll see clock of up to 2.8GHz under a 750mW power budget (SPEC2K workload). This seems a rather conservative figure and I’m not sure if vendors will follow ARM’s guidance here – it’s more likely we’ll see SoCs try to hit and go over 3GHz on 10nm while the 2.8GHz target seems perfectly doable on 16nm. Of course this all depends on if the vendors are able to do a physical implementation that is close to ARM’s POP results, such as HiSilicon’s Kirin 950.

Closing Thoughts

Overall ARM’s decisions with the A73 make a lot of sense. ARM's big cores definitely needed to improve in terms of power and efficiency. A72 was a first step towards that goal and A73 further improves in that regard. In the future we should expect ARM to eventually again return to wider microarchitectures as we hit the wall of diminishing returns in terms of frequency scaling. HiSilicon's Kirin 950 was a game-changer in terms of perception and analysis of ARM’s microarchitectures as we finally have a vendor that was able to hit power figures near those that ARM publishes, lending the latter much more credibility when talking about efficiency goals.

If the A73 is able to hit all of its promised targets then it leaves me with some doubt on what this means for vendors who are currently using their own microarchitectures. Apple has proven that they’re able to execute and deliver outstanding performance at high efficiency, but vendors such as Qualcomm and Samsung aren’t in an as good position. We'll have a more in depth discussion about Snapdragon 820’s Kryo and Exynos 8890’s Mongoose cores in an upcoming deep dive article, but both microarchitectures have trouble in terms of differentiating themselves in terms of performance and power compared to ARM’s own current designs, casting some doubt on how they'll be able to evolve and compete against SoCs using Artemis cores.

ARM states that we’ll be seeing SoCs and actual consumer devices with A73 by the end of the year. This would mark the second year in a row where vendors would be ship within less than a year from announcement of a new ARM microarchitecture, and given the stated release schedule and looking back at last year’s SoCs with A72 cores, it shouldn't be too hard to guess which device and chipset might be able to fit this timeline.

All in all, I’m pretty happy with the direction ARM went with in the A73. It addresses a lot of the issues brought up in the introduction, and while more performance is always wanted, efficiency needed to be in focus this generation, and efficiency we got.

The Cortex A73 Microarchitecture
Comments Locked

63 Comments

View All Comments

  • CodeJingle - Saturday, June 11, 2016 - link

    It has nothing to do with Apple, it is completely obvious jumping from 32-bit to 64-bit means one of the processor generations has to take one for the team.
  • SanX - Tuesday, June 21, 2016 - link

    Please use solid or more distinctive colors for curves, with these washed out colors absolutely impossible to understand what is what
  • GXCoder - Tuesday, July 5, 2016 - link

    When will you publish the comparative data between kryo and M1 cores?

Log in

Don't have an account? Sign up now