The Cortex-X2: More Performance, Deeper OoO

We first start off with the Cortex-X2, successor to last year’s Cortex-X1. The X1 marked the first in a new IP line-up from Arm which diverged its “big” core offering into two different IP lines, with the Cortex-A sibling continuing Arm’s original design philosophy of PPA, while the X-cores are allowed to grow in size and power in order to achieve much higher performance points.

The Cortex-X2 continues this philosophy, and further grows the performance and power gap between it and its “middle” sibling, the Cortex-A710. I also noticed that throughout Arm’s presentation there were a lot more mentions of having the Cortex-X2 being used in larger-screen compute devices and form-factors such as laptops, so it might very well be an indication of the company that some of its customers will be using the X2 more predominantly in such designs for this generation.

From an architectural standpoint the X2 is naturally different from the X1, thanks in large part to its support for Armv9 and all of the security and related ISA platform advancements that come with the new re-baselining of the architecture.

As noted in the introduction, the Cortex-X2 is also a 64-bit only core which only supports AArch64 execution, even in PL0 user mode applications. From a microarchitectural standpoint this is interesting as it means Arm will have been able to kick out some cruft in the design. However as the design is a continuation of the Austin family of processors, I do wonder if we’ll see more benefits of this deprecation in future “clean-sheet” big cores designs, where AArch64-only was designed from the get-go. This, in fact, is something that's already happening in other members of Arm's CPU cores, as the new little core Cortex-A510 was designed sans-AArch32.

Starting off with the front-end, in general, Arm has continued to try to improve what it considers the most important aspect of the microarchitecture: branch prediction. This includes continuing to run the branch resolution in a decoupled way from the fetch stages in order to being able to have these functional blocks be able to run ahead of the rest of the core in case of mispredicts and minimize branch bubbles. Arm generally doesn’t like to talk too much details about what exactly they’ve changed here in terms of their predictors, but promises a notable improvement in terms of branch prediction accuracy for the new X2 and A710 cores, effectively reducing the MPKI (Misses per kilo instructions) metric for a very wide range of workloads.

The new core overall reduces its pipeline length from 11 cycles to 10 cycles as Arm has been able to reduce the dispatch stages from 2-cycles to 1-cycle. It’s to be noted that we have to differentiate the pipeline cycles from the mispredict penalties, the latter had already been reduced to 10 cycles in most circumstances in the Cortex-A77 design. Removing a pipeline stage is generally a rather large change, particularly given Arm’s target of maintaining frequency capabilities of the core. This design change did incur some more complex engineering and had area and power costs; but despite that, as Arm explains in, cutting a pipeline stage still offered a larger return-on-investment when it came to the performance benefits, and was thus very much worth it.

The core also increases its out-of-order capabilities, increasing the ROB (reorder buffer) by 30% from 224 entries to 288 entries this generation. The effective figure is actually a little bit higher still, as in cases of compression and instruction bundling there are essentially more than 288 entries being stored. Arm says there’s also more instruction fusion cases being facilitated this generation.

On the back-end of the core, the big new change is on the part of the FP/ASIMD pipelines which are now SVE2-capable. In the mobile space, the SVE vector length will continue to be 128b and essentially the new X2 core features similar throughput characteristics to the X1’s 4x FP/NEON pipelines. The choice of 128b vectors instead of something higher is due to the requirement to have homogenous architectural feature-sets amongst big.LITTLE designs as you cannot mix different vector length microarchitectures in the same SoC in a seamless fashion.

On the back-end, the Cortex-X2 continues to focus on increasing MLP (memory level parallelism) by increasing the load-store windows and structure sizes by 33%. Arm here employs several structures and generally doesn’t go into detail about exactly which queues have been extended, but once we get our hands on X2 systems we’ll be likely be able to measure this. The L1 dTLB has grown from 40 entries to 48 entries, and as with every generation, Arm has also improved their prefetchers, increasing accuracies and coverage.

One prefetcher that surprised us in the Cortex-X1 and A78 earlier this year when we first tested new generation devices was a temporal prefetcher – the first of its kind that we’re aware of in the industry. This is able to latch onto arbitrary repeated memory patterns and recognize new iterations in memory accesses, being able to smartly prefetch the whole pattern up to a certain depth (we estimate a 32-64MB window). Arm states that this coverage is now further increased, as well as the accuracy – though again the details we’ll only able to see once we get our hands on silicon.

In terms of IPC improvements, this year’s figures are quoted to reach +16% in SPECint2006 at ISO frequency. The issue with this metric (and which applies to all of Arm’s figures today) is that Arm is comparing an 8MB L3 cache design to a 4MB L3 design, so I expect a larger chunk of that +16% figure to be due to the larger cache rather than the core IPC improvements themselves.

For their part, Arm is reiterating that they're expecting 8MB L3 designs for next year’s X2 SoCs – and thus this +16% figure is realistic and is what users should see in actual implementations. But with that said, we had the same discussion last year in regards to Arm expecting 8MB L3 caches for X1 SoCs, which didn't happen for either the Exynos 2100 nor the Snapdragon 888. So we'll just have to wait and see what cache sizes the flagship commercial SoCs end up going with.

In terms of the performance and power curve, the new X2 core extends itself ahead of the X1 curve in both metrics. The +16% performance figure in terms of the peak performance points, though it does come at a cost of higher power consumption.

Generally, this is a bit worrying in context of what we’re seeing in the market right now when it comes to process node choices from vendors. We’ve seen that Samsung’s 5LPE node used by Qualcomm and S.LSI in the Snapdragon 888 and Exynos 2100 has under-delivered in terms of performance and power efficiency, and I generally consider both big cores' power consumption to be at a higher bound limit when it comes to thermals. I expect Qualcomm to stick with Samsung foundry in the next generation, so I am admittedly pessimistic in regards to power improvements in whichever node the next flagship SoCs come in (be it 5LPP or 4LPP). It could well be plausible that we wouldn’t see the full +16% improvement in actual SoCs next year.

2022 Generation: Moving Towards Armv9 The Cortex-A710: More Performance with More Efficiency


View All Comments

  • mode_13h - Wednesday, May 26, 2021 - link

    > Android needs to get their developers to stop using Java and use C/C++/Rust for their apps to eek out the max performance possible.

    No, I'm sure Google would rather they use Go.

    Also, unless you compile your C++ to web asm, it has the disadvantage of leaving out users on newer devices not supported by the NDK version where you built your app. Like RISC V, for instance. Interpreted languages and those that compile into a portable intermediate representation don't have this problem.

    > it's a long time nagging issue that I wish the Android community would solve.

    Your best hope is that Web Assembly takes over, then.
  • hlovatt - Thursday, May 27, 2021 - link

    > Android needs to get their developers to stop using Java and use C/C++/Rust for their apps to eek out the max performance possible.

    > Apple's App code base is generally C/C++, that's why they have the performance

    Apple code is mainly Objective-C and Swift (neither are particularly fast).


    These benchmarks are largely discredited because they include the start up time in the measurements, which unrealistically hampers virtual machines as used by Java. Its like opening your mailer, typing a couple of characters, and then shutting down your mailer, opening your mailer again, another couple of characters, repeat. Then saying you mailer is slow. Most apps are long running and counting the opening and closing down of the virtual machine for a small task doesn't give useful results.
  • mode_13h - Wednesday, May 26, 2021 - link

    > Apple is in a very very special situation where they control everything. Hardware,
    > software, product. Plus they use the best process there is at the moment.
    > All of this, contributes to their results. Which are very good, but they stem from
    > what I told you.

    They get a benefit from using the latest process, but that doesn't help them relative to anyone else on that same process node. ARM probably does as much work or more to port their IP to a process node & libraries as Apple does.

    They *do* get a benefit from controlling the OS. I'll grant you that. The main thing that can probably help is dialing in clockspeed & thermal management, as well as how load-balancing with the low-power cores is managed.

    However, the rest of it is irrelevant for SPEC scores, because the Anandtech team uses the same compilers and the SPEC source is also the same.

    > Their cores are not exactly suited for the plethora of android devices that range from 50 bucks to 2000+.

    Well, the upper end of that range, yes. That's the biggest thing Apple has in their favor: bigger budgets for bigger cores on newer nodes.

    > ARM cpus lose compatibility totally once in a while, which is not something that will work in the long run.

    Seems like little-to-no burden for ARMv9 CPUs to retain ARMv8 compatibility, though. When they go to ARMv10, that might be a different story.

    > Intel hasn't introduced anything major since 2015!

    If Sunny Cove doesn't count as something new, then I think your standards are unrealistic.

    BTW, if you want bigger micro-architectural changes, try Gracemont.
  • Silma - Tuesday, May 25, 2021 - link

    Apple & ARM benefit from the best foundries in the world, which has not been the case for Intel for at least 3 years.
    If Intel catches up in production tech or gets access to the same process than Apple and Co, we'll see who has the better designs for which workloads.
  • melgross - Tuesday, May 25, 2021 - link

    I do think that Intel’s designs are better than AMD designs. They’re not that much s,owner, when they are, and and is on a smaller, faster node. But as far as Apple’s designs, I doubt it. The designs are too different to make that claim. Additionally, and SoC is far more than just CPU cores. That just a fifth of Apple’s SoC. Reply
  • igor velky - Tuesday, May 25, 2021 - link

    AMD didnt invent multichip modules, those are lies !

    IBM had servers with multichip cpus in like 1985ish
    Intel Core2 had some cpus which were MCM, too.
    ten or so years ago.
  • mode_13h - Wednesday, May 26, 2021 - link

    > Intel Core2 had some cpus which were MCM

    The Pentium Pro had its L2 cache on a separate die.
  • kgardas - Tuesday, May 25, 2021 - link

    x86 is dead? Well, it is, welcome amd64.
    Anyway, I would not consider latest Zen or Sunny Cove/Willow Cove cores as non-competitive even with the latest Apple Mx designs. IMHO they are doing fine. Now, do you know that Alder Lake/Sapphire Rappids will have Golden Cove? And that should arrive this and early next year probably. The core should again provide quite nice bump in IPC. So both ARM and even Apple will have again more than adequate competition. No, neither intel nor amd are dead. Pretty exciting times ahead...
  • GeoffreyA - Tuesday, May 25, 2021 - link

    Oh boy, here we go again. x86, dead. Apple M1, enchanted stuff. Intel/AMD, rubbish for the dump. All hail, Apple! Reply
  • Silver5urfer - Wednesday, May 26, 2021 - link

    Logically their tunnel vision has only 2 possible reasons

    One - Apple hardcore fans and somehow their daily tasks and lives rely only on Mac OS or iOS, ignorant on the reality and dumb to believe SPEC and Apple marketing PR.

    Two - They hate Intel a lot and also PC platform a lot, have a console probably and a Macbook BGA junk.

    I do not know what else and why would anyone hate x86 processors from Intel and AMD, I do not see any point since they are the PCs we can own today and they will last literally for decades. People are using old school Xeon for home server and old school pre SSE4.2, basically Phenom II and Intel Core 2 Quad Q6600 Processors to play damn latest games with community patches for .exes, then we have the latest HW for PC in HEDT and Mainstream for multiple use cases.

    Why would anyone hate the only processing standard which has excellent backwards compat full blown parts system for DIY and repair etc, and literally choice of your own OS - Linux, Windows and some Intel HW for Hackintosh. Yep they are dumb and ignorant for sure.

Log in

Don't have an account? Sign up now