Arm Announces Armv9 Architecture: SVE2, Security, and the Next Decade
by Andrei Frumusanu on March 30, 2021 2:00 PM ESTFuture Arm CPU Roadmaps
Not directly related to v9, however tied into the technology roadmap of the upcoming v9 designs in the near future, Arm also talked about some points regarding their projected performance of v9 designs in the next 2 years.
Arm talked about how the mobile space had seen performance increases of 2.4x (we’re talking purely ISO-process design IPC here) of this year’s X1 devices compared to the Cortex-A73 a few years ago in 2016.
Interestingly, Arm also talked about Neoverse V1 designs and how they’re achieving 2.4x the performance of A72 class designs, and discloses that they are expecting the first V1 devices to he released later this year.
For the next-generation mobile IP cores, code-named Matterhorn and Makalu, the company is disclosing an aggregate expected 30% IPC gain across these two generations, excluding frequency or any other additional performance gains which could be reached by SoC designers. This actually represents a 14% generational increases across these two new designs, and as showcased in the performance curve in the slide, would indicate that improvements are slowing down relative to what Arm had managed over the past few years since the A76. Still, the company states that the rate of advancement is still well beyond the industry average – admittedly that is being dragged down by some players.
Oddly enough, Arm also included a slide that wanted to focus on the system-side impact on performance, rather than just CPU IP performance. Some of the figures presented here, such as 1% of performance per 5ns of memory latency have been figures that we had talked about extensively for a few generations now, but Arm here also points out that there’s a whole generation of CPU performance that can be squeezed out if one focuses on improving various other aspects of an implementations by improving the memory path, increasing caches, or optimising frequency capabilities. I consider this to be a veiled shot at the current conservative approaches from SoC vendors which are not fully utilising the expected performance headroom of X1 cores, and subsequently also not reaching the expected performance projections of the new core.
Arm continues to see the CPU as the most versatile compute block for the future. While dedicated accelerators or GPUs will have their place, they have a hard time to address important points such as programmability, protection, pervasiveness (essentially ability to run them on any device), and proven abilities to work correctly. Currently, the compute ecosystem is extremely fragmented in how things are run, not only differing between device types, but also differing between device vendors and operating systems.
SVE2 and Matrix multiplication can vastly simplify the software ecosystem, and allow compute workloads to take a step forward with a more unified approach that will be able to run on any device in the future.
Lastly, Arm had a nugget of new information on the future of Mali GPUs, disclosing that the company is working on new technologies such as VRS and in particular Ray Tracing. The latter point is quite surprising to hear, and signals that the desktop and console ecosystem push by AMD’s and Nvidia’s introduction of RT is also expected to push the mobile GPU ecosystem towards RT.
Armv9 designs to be unveiled soon, devices in early 2022
Today’s announcement came in an extremely high-level format, and we expect Arm to talk more about the various details of Armv9 and new features such as CCA in the company’s usual yearly tech disclosures in the coming months.
In general, Armv9 appears to be a mix between a more fundamental ISA shift, which SVE2 can be seen as, and a general re-baselining for the software ecosystem to aggregate the last decade of v8 extensions, and build the foundation for the next decade of the Arm architecture.
Arm had already talked about the Neoverse V1 and N2 late last year, and I do expect the N2 at least to be eventually unveiled as a v9 design. Arm further discloses to expect more Armv9 CPU designs, likely the mobile-side Cortex-A78 and X1 successors, to be unveiled this year, with the new CPUs likely to have already been taped-in by the usual SoC vendors, and expected to be seen in commercial devices in early 2022.
Facebook
Twitter
RSS
74 Comments
View All Comments
JoeDuarte - Wednesday, March 31, 2021 - link
This is not true. Most developers have never used any SIMD and don't plan to. Some of them don't even know what SIMD is. You're severely overestimating its importance. Software developers are generally lazy and produce lots of underperforming and poorly optimized code.Given that Arm introduced SVE several years ago, and no one has even implemented it in a processor that you can buy, I don't know why you think Arm's noises about SVE2 matter. It won't matter. They're so fragmented that they can't even get consistent implementation of the latest versions of v8, like v8.3/4/5.
Apple doesn't even want developers to optimize at that level, to use assembly or intrinsics, so they make it hard to even know what instructions are supported in their Arm CPUs. They want everyone to use terrible languages like Swift. On Android, there's so much fragmentation that you can't count on support for later versions of v8.x.
SVE2 would matter on servers if and when Arm servers become a thing, a real thing, like a you can buy one from Supermicro kind of thing. They would need to be common, with accessible hardware. Developers will need access to the chips, either on their desks or in the cloud. It would need to be reliable access – the cloud generally isn't reliable that way, as there have been cases where AWS dropped people down to instances running on pre-Haswell CPUs, which broke developers' code using AVX2 instructions...
You can't develop for SVE2 without access to hardware that supports it. Right now that hardware does not exist. Arm v9 isn't going to yield any hardware that supports SVE2 for a year or longer, and it might be four years or so before it's easily accessed, or longer, possibly never. By the time it's readily available, so many other variables will have changed in the market dynamic between Arm, AMD, and Intel that your claim doesn't work.
Ppietra - Friday, April 2, 2021 - link
A lot of developers might not even know what SIMD is, but I would argue that a lot of apps actually end up using SIMD simply because many APIs to the system make use of NEONKrysto - Tuesday, March 30, 2021 - link
MTE will likely end up more of a short-term solution, as all such solutions are.If Arm was serious about actually getting rid of the majority of memory bugs, they would have announced first-class support for the Rust programming language.
SarahKerrigan - Tuesday, March 30, 2021 - link
https://developer.arm.com/solutions/internet-of-th...Rust has been well-supported on ARM for a while.
Wilco1 - Wednesday, March 31, 2021 - link
Many languages have claimed to solve all computing problems, but none did as well as C/C++. Why would Rust be any better than Java, C#, D, Swift, Go etc?Also you're forgetting that compilers and runtimes will still have bugs. 100% memory safe is only achievable using ROM.
kgardas - Wednesday, March 31, 2021 - link
Because from all mentioned languages, Rust is not GC-based language and has highest chance to be involved in system programming. See Rust addition into the Linux kernel. See MS praise for Rust etc. Generally speaking Rust is more typesafe/memory safe than C, and good old C is really old enough to be replaced completely.Wilco1 - Wednesday, March 31, 2021 - link
Ditching GC is good but it doesn't solve the fundamental problem. I once worked on a new OS written in a C# variant, and it was riddled with constructs that switch off type checking and GC in order to get actual work done. So in the end it didn't gain safety while still suffering from all the extra overheads of using a "safe" language.So I remain sceptical that yet another new language can solve anything - it's hard to remain safe while messing about with low level registers, stacks, pointers, heaps etc. Low-level programming is something some people can do really well and others can never seem to master.
mdriftmeyer - Thursday, April 1, 2021 - link
We're not talking C89 but C17 and most OS solutions are already implementing those modern features. C2x has an awful lot of work being finalized into it.http://www.open-std.org/jtc1/sc22/wg14/www/wg14_do...
Good old C isn't old anymore.
And no, Linus, Apple, Microsoft aren't ditching C/C++ in their Kernels for Rust.
melgross - Saturday, April 10, 2021 - link
Rust will be safer until the hacking community is interested enough to find all of the bugs and poor thinking that undoubtedly exists in Rust, as it has in every language over the decades that was declared safe.JoeDuarte - Wednesday, March 31, 2021 - link
Are you aware of formal verification? There are formally verified OSes now, like seL4.There's also the CHERI CPU project, which Arm in involved in.
And formally verified compilers line INIFRIA.
We need to junk C and C++ and replace them with serious programming languages that are far more intuitive and sane, as well as being memory safe. Rust is terrible from a syntax and learning standpoint, and much better languages are possible. The software industry is appallingly lazy.