ARMv9 What is the Big Deal
By: Erik Engheim
Tags: Apple, Microprocessor, Hardware, Arm

ARMv9: What is the Big Deal?

What is a Scalable Vector Extension? What does it mean to the industry and users? What is behind the jargon? Erik Engheim Follow Apr 3 · 22 min read

If you are a cellphone user, then you know ARM chips: they power your phone, and now they are powering the next generation Macs. They are also making major inroads into the server space.

We are at a cusp of a major shift in industry, the likes of which has not been seen in decades. Yes, this sounds dramatic, but x86 has been dominating the computing industry for decades, and is likely facing its biggest challenge ever with the rise of ARM.

This battle won’t be settled this year, but now ARM has released their next generation architecture ARMv9, which will set the course of the industry for a decade. It is thus a very significant event that deserves some scrutiny.

There are many items to talk about here, but to me the big topic is the standardization on what is called the Scalable Vector Extension 2 (SVE2). You have probably heard about SIMD instruction-sets such as MMX, SSE2, AVX, AVX-512 from Intel or the older Neon from ARM. However, you might not know exactly what these are for, other than in a superficial sense. I will try to explain what makes SVE/SVE2 so different from these older SIMD instruction-sets.

And did you know that Fujitsu has played a significant role in all of this? We are seeing a sort of return to old-school super-computing as found in the Cray-1 super computers from decades ago. The Cray company is in fact not dead yet, but is actually busy building ARM based super-computers: LRZ to Deploy HPE’s Cray CS500 System with Arm Fujitsu A64FX Processors.

The Cray-1 supercomputer, c. 1976. It was approximately 6 feet high and 7 feet in diameter (1.8 by 2.1 metres).

Is ARMv9 a Physical Chip I Can Buy in the Store?

This isn’t the same as when AMD or Intel release a new microprocessor that you can buy and stick in your PC to get higher performance. It is not a physical thing. Rather, this is a new microprocessor architecture, backwards compatible with previous ARM architectures such as ARMv8.

Let me elaborate on how this works. Lots of companies around the world such as Qualcomm, Apple, Fujitsu, Ampere Computing, Amazon and many others design their own chips. This works in several steps. For example, neither Apple nor AMD actually manufacture their own microchips. Instead they design chips and then ship the design to what we call a foundry such as Global Foundries or TSMC. They take the design and etch it onto silicon wafers that are then cut into microchips and packaged.

ARM Ltd. is not like Qualcomm or Ampere Computing. They don’t make the final blueprint that is shipped to a semi-conductor foundry. Instead ARM sells intellectual buildings blocks or IP. Companies such as Apple can buy these various designs and compose them into a final blueprint that they ship off to TSCM for manufacture.

An ARM Neoverse N1 based SoC maufactured by TSMC

But this comes in different flavors. For example, there are blueprints for for actual microprocessor cores such as the Neoverse N1. A company can buy this design from ARM and sit with their design tools and copy-paste four N1 cores on their screen, draw some connection lines, drag out some cache memory blocks, make some connections. Boom, they have a new microprocessor. Okay, a bit more complicated than that, but you get the general idea.

ARMv9, like ARMv8 before it, is not a specific concrete design like that. It is not a blueprint that says: transistors are connected in this or that pattern. How you lay out your transistors to create a high performance design is what we call micro-architecture.

ARMv9 is a contract between compiler writers and hardware designers. It is a common agreement on what the interface to a particular ARM processor is supposed to look like. What instructions to support and how they work. But it says nothing about how that is achieved in terms of transistors.

ARMv9 in contrast is the CPU architecture, and is something more abstract. It is more like a contract between the hardware and the software. It says what hardware registers are supposed to be on your microprocessor. How many bits they contain (binary digits). It say what operations are supported. Operations are things like adding two 32-bit numbers or multiplying two 64-bit floating point numbers and storing the result in another register.

Example of CPU instructions, for loading numbers from memory location 14 and 24 respectively and storing in register x1 and x2 . Adds registers and stores result in register x3 .

load x1, 14 ; x1 ← memory[14]

load x2, 24 ; x2 ← memory[24]

add x3, x1, x2 ; x3 ← x1 + x2

For more details read my article How Does a Modern Microprocessor Work?

A CPU architecture is important for tool makers. Software like compilers and linkers target a CPU architecture. This means when ARM Ltd. has made ARMv9, they have made a common standard for software developers and hardware makers. As long as Qualcomm, Apple, Ampere and others make hardware that understands instructions specified by the ARMv9 specification, then software producing code for this specification will also run.

Naturally as part of such an effort, ARM will have been making micro-architectures that actually implement this new ARMv9 standard. However, this will just be one in a long series of micro-architectures that we will see for probably the next 10 years. In that period we will see lots of different hardware but it will all be able to run code made for the ARMv9 specification.

What is New in ARMv9?

To get some sense of what such specifications entails, it might be worth mentioning what ARMv8 meant. ARMv8 was released eight years ago and was the first 64-bit architecture that ARM Ltd. introduced. Chips based on the ARMv7 architecture was 32-bit. That meant registers inside the CPU could only operate on numbers that had a maximum of 32 binary digits.

ARMv8 was a pretty big thing for Apple as they took the industry by surprise by a rapid and aggressive early move to 64-bit ARM architecture. This gave the iPhone and iPad a head start on the competition. No doubt Apple wanted to get into high performance architectures early on as they had aims for ARM desktop chips.

To simplify a bit, you could say ARMv8 was the ARM architecture for desktop computing. ARM took the step out from cell phones and into the world of desktop computers and servers.

ARMv9 in contrast is all about the super-computer. This may make you think it has no implication for you as a cellphone user of desktop computer user. However you would be wrong. This has a lot to do with consumers as well.

I haven’t covered what the big deal is about vectors or what they even are. However they are a big deal in science. The old super computers such as Cray-1 was built around processing massive amounts of vectors. They were what we call vector processing machines.

When I was a teenager and read about Cray computers, I did not grasp what this meant. I used to fantasize with my buddies about what kind of frame rate we would get playing DOOM on a Cray. But it would likely have made little difference. What Cray excelled at was scientific computations such as running weather simulations, drug simulations and all sorts of data analysis and processing. Anything involving huge tables of data, with lots of rows and columns, benefit from vector processing.

This is what is coming to ARMv9 through an addition of a whole host of new microprocessor instructions called SVE2, or Scalable Vector Extension 2. In other words ARM CPUs are becoming more like the super-computers of old.

Read more: ARM, x86 and RISC-V Microprocessors Compared.

A Super-Computer in Your Pocket

But why is ARM getting super-computer style architecture today? What is going on?

Have you noticed how things like face recognition, speech recognition, self-driving and machine learning have become far more common? You got intelligent assistants like Siri giving you heads up about meetings, answering questions. Now this may seem like old hat by now, but have you reflected on how these solutions have worked in the past?

Whenever you spoke something to your digital assistant, the recording would be sent over the network to the cloud where the equivalent of a super computer would analyze your voice and determine what you said before sending the result back to your phone. Today we are trying to spread this kind of intelligence much wider to more devices all over the place. All of these devices cannot have high speed internet connections sucking up massive amounts of bandwidth.

Also users don’t want to have to always be connected to interact with their digital assistance, do speech recognition, face recognition and other tasks. We want these tasks always available and on much cheaper and ubiquitous devices. It turns out that these kinds of tasks mirrors what classic super-computers such as the Cray-1 used to do. Thus what was once old is now new.

I cover this in more detail here: RISC-V Vector Instructions vs ARM and x86 SIMD.

ARM Enters High Performance Computing

After desktops and servers, the next step is naturally High Performance Computing (HPC). Actual super computers. Far back this was dominated by custom hardware solutions like ARM, before large data centers containing commodity hardware such as x86 computers with beefy graphics cards took over.

Intel and AMD has been making good money on this market as machine learning and data analysis have become far more mainstream and important in the economy. ARM naturally wants to take a big bite out of this market. Fujitusu’s A64FX ARM based microprocessor was the first shot fire.

Fujitsu had experience building these kind of Cray style super computers using vector processing. They partnered with ARM to extend ARM processors with a new instruction-set called SVE, Scalable Vector Extension. While ARM was already far along in this design, Fujitsu helped a lot by giving input based on their super-computing experience.

This combination was used to create the A64FX which formed the basis for building the worlds most powerful supercomputer: Japan’s Fugaku gains title as world’s fastest supercomputer.

The A64FX is an ARMv8 based CPU designed by Fujitsu for use in high performance computing. It was the first chip with the scalable vector extension.

But here is a very important fact to be aware of. This was an extension and not part of the ARMv8 base specification. Your ARMv8 based iPhone or iPad e.g. could not have run code made for the Fugaku super computer because they simply lacked support for SVE microprocessor instructions.

In ARMv9 in contrast these kinds of instructions becomes part of the standard. That is why I say ARM is a putting a super-computer in your pocket.

But there is a deeper story her which requires getting into more of the details. You see ARM is doing this in a way, where they can offer processors for the cheapest embedded devices all the way to the most expensive super-computers, while making all of them capable of running the same code.

And they are doing it in a way where much more regular code can gain performance than what has been possible before. This kind of stuff is simply not possible with the solutions Intel and AMD have pursued with the AVX instructions for their x86 microprocessors.

To understand better why, we need to look more in detail at the differences and similarities between vector processing and SIMD instructions. But first, what is a vector?

You can look at vectors in many ways. Either just as a bunch of numbers. But really they represent displacement in space. Such as arrows. The (x, y) of a point says where the point is in a coordinate system. The (x,y) of a vector says how far the vector stretches along the x-axis and y-axis. The reason vectors can have a lot more numbers is because they are not limited to 2D and 3D space. They can also exist in imaginary space with hundreds if not thousands of dimensions. In mathematics anything you can imagine is possible.

What is a Vector Anyway?

A vector is just fancy mathematical speak for a list of numbers. Often we would write them like this:

[3, 5, 9]

It is practical to be able to work with lists of numbers by referring to them using a name or an identifier. Thus here I am making two vectors named v1 and v2 :

v1 ← [3, 2, 1]

v2 ← [1, 2, 2]

And here is a way of expressing that I am adding the vectors and storing the result in v3 :

v3 ← v1 + v2 ; v3 should now contain [4, 4, 3]

Why the arrow ( ← ) notation? When explaining what is going on inside a computer this is useful because we usually have some area of memory where we are storing numbers. This memory could be numbered or named. Inside the microprocessor we got a small chunk of memory called the register file, which is divided into separate chunks called registers. On an ARM microprocessor these registers have names such as x0 , x1 ... x31 or they can be named v0 , v1 ... v31 .

To be able to perform operations such as adding, subtracting or multiplying numbers, they need to be moved from memory into one of these registers. You cannot directly add two numbers stored in main memory. The CPU only does operations on numbers stored inside its register file.

In this simplified diagram of a microprocessor the Register File is the gray box marked Registers. Numbers from memory is transmitted to it along colored lines called buses. The Register File feeds input to the ALU, FPU, LSU and other units which performs actual calculations and operations.

By the way to avoid any confusion. The register file has nothing to do with files on your hard drive. It is just a block of memory inside the CPU which can be utilized in arithmetic and logical operations.

The opposite of vectors are scalars. That is just a fancy word for single numbers. So here is a simple example of scalar operations using the previous notation:

x1 ← 3 ; store 3 in x1

x2 ← 4 ; store 4 in x2

x2 ← x1 + x2 ; adding x1 and x2 gives 7

Vectors are used for lots of things. Even if you are not a programmer, you have probably used a spreadsheet application such as Microsoft Excel. A column in a row, could be thought of as a vector. We commonly treat it as one logical unit. E.g. we might add up all the elements in a column or we add each cell in one column with the cell on the same row in another column. This is the same thing that happens when you add two vectors inside a CPU. Together multiple columns form tables. In mathematical speak we would say that multiple vectors form matrices. Basically collection of numbers organized in rows and columns.

You can think of Amount and Unit Cost as vectors. The total cost is the result of element-wise mathematical computations on these two vectors.

These are a big deal in machine learning or pretty much any scientific work. The first programmable computer, the Z1 was in fact created to perform matrix calculations.

While todays computers don’t typically work directly on matrices, we can easily speed up matrix calculations by using vectors. That is why vector instructions are so important to speed up machine learning, image recognition and speech recognition. The mathematics of vectors and matrices is called Linear Algebra. I got an intro for the curious among you: The Core Idea of Linear Algebra.

But let us not get lost in the math. What we are really after is how this related to microprocessors. The instructions in a modern microprocessor used for dealing with vectors are called SIMD instructions.

SIMD vs Vector Instructions

Technically speaking both ARMs Neon and SVE instructions are a form of SIMD instructions. It is an abbreviation, which is short for Single Instruction Multiple Data. What we mean with instructions are things like add, subtract and multiply. Thus the idea of SIMD is that you issue a single instruction to the CPU and then it perform this same operation on multiple values, all at the same time.

Single Instruction Single Data (SISD) vs Single Instruction Multiple Data (SIMD)

These kinds of instruction-sets have been around for a while. You have probably heard about the MMX, SSE and now AVX instruction-sets on Intel and AMD x86 microprocessors. They came around to do multimedia processing such as video encoding and decoding more quickly. ARMs Neon instructions are most similar to these. These Neon instructions look like this:

LDR v0, [x4] ; v0 ← memory[x4]

LDR v1, [x6] ; v1 ← memory[x6]



ADD v4.16B, v0.16B, v1.16B

STR v4, [x8] ; v4 → memory[x8]

In this example, the scalar registers x4 , x6 and x8 are holding memory addresses, places in memory where we want to load numbers from and store results from calculations.

LDR is a the ARM instruction for loading numbers from memory into a register in the register file. STR does the opposite and stores numbers found in a register in main memory.

The ADD instruction probably looks peculiar. Why the weird suffix like .16B after each register name?

Lanes in Vector Processing

A vector register such as v0 and v1 are 128-bits wide. What does that mean? It is basically the max number of binary digits a vector register can hold.

This sets an upper limit for how many numbers we can perform operations on in parallel and how how many binary digits (bits) each of these numbers can have. For instance if you want to add up 64-bit numbers, then you can only add two in parallel because you can only fit two 64-bit numbers within a 128-bit vector register. However if you use small numbers you can fit more. E.g. when working with color values, we typically represent the red, green and blue component as an 8-bit value. We can fit 16 of these within a 128-bit register.

128/8 = 16

Thus this should give you a hint. 16B means sixteen byte-wide elements. Try to guess what this add instruction means:

ADD v4.2D, v0.2D, v1.2D

In microprocessor jargon, we usually call a 32-bit number for a word. A 64-bit value is a double-word. Hence .2D means two double-words. .4S would mean four single-words:

128/32 = 4

But why does only the add instruction have these suffixes? Why not the load and store? Because when we are loading and storing we don’t need to treat each the vector registers as being composed of multiple elements.

The number of elements we split a register into during a calculation decides how many lanes are setup for computations. Think about a road system, where numbers are flowing in parallel along multiple lanes. Below is an example of this. We got the v1 and v2 registers used in a calculation where the result gets stored in v3 . We split into two elements .2D and thus we have two lanes performing calculations. Each lane gets one ALU (Arithmetic Logic Unit).

How multiple ALUs are used to allow SIMD execution. We got two lanes of computation. Each lane is handled by one Arithmetic Logic Unit (ALU).

If you don’t like my illustration, then ARM has another one illustrating the concept with four separate lanes for addition.

Four-lane addition between v8 and v9 register

The Problem with SIMD Instructions

SIMD instructions such as the ones you see below, may look like the same instruction with different arguments:

ADD v4.2D, v0.2D, v1.2D

ADD v4.4S, v0.4S, v1.4S

However these get encoded as separate instructions. This quickly goes out of control as well illustrated on the x86 side of things. Intel began with MMX, then came SSE, SSE2, AVX, AVX2 and finally AVX-512. MMX e.g. had 64-bit vector registers so you could e.g. do two 32-bit values in parallel or eight 8-bit values.

Over time as they got more transistors available, they decided to make available new and larger vector registers. SSE2 e.g. has 128-bit vector registers. Eventually that was not enough and so you got AVX and AVX2 gave us 256-bit vector registers. Now finally AVX-512 has given us the crazy long 512-bit vector registers. So now you could in principle compute sixty-four 8-bit color values in parallel.

Every time Intel made larger registers available, they had to add a ton of new instructions. Why? Because the length of the vector register is encoded in the SIMD instruction. This quickly gets bloated. You will need an ADD instruction for:

Every vector register width 64, 128, 256 or 512 bits. Every one of these need an separate variant for the number of lanes used.

Thus the addition of SIMD instructions has led to an explosion in the number of instructions, especially for x86. And of course not every x86 processor will support all these instructions. Only the newer ones will support AVX-512.

Why ARM Could Not Follow the AMD and Intel Strategy

This strategy is unworkable for ARM. Intel and AMD have a simple mission. They are just trying to make the biggest meanest CPUs they can possibly make at all times and push them to the market.

ARM in contrast is trying to cover a very wide spectrum of needs. ARM runs on tiny embedded devices all the way up to super computers like the Fugaku. ARM may be able to offer CPU designs for server using 512-bit vectors, but supporting that on a tiny an an ARM meant to run on a budget phone with long battery life will be impossible. Sure ARM could make lots of different instruction-sets available.

And indeed ARM does offer different profiles for different market segments. But it is still in ARMs interest that the same software can compile and work across a wide variety of their chips.

What SVE and SVE2 allows ARM to do is to give different physical length of vector registers for each type of chip the sell designs for. With SVE/SVE2 a vector register has to have a minimal length of 128-bit and a maximum length of 2048-bit. For low-power smart-phones they can sell designs with 128-bit vector length. For super-computers they could sell designs with 2048-bit wide vectors.

The beauty of SVE is that the same code will work for both the super-computer and the cheap phone. That is not possible with the x86 SIMD instructions. While I am not an ARM assembly code expert, based on what the assembly code looks like when using Neon and SVE, it looks to me as if the latter will be more efficient. Even if the vector-register length is the same.

The reason is that you get much shorter assembly code. That means fewer instructions to fit into cache. Fewer instructions to decode and manage. Let me clarify what I mean by that. When a microprocessor receives a instruction from memory, telling it to e.g. add two numbers or multiply them, then it needs to actually figure out what the instruction is telling it to do. That is called decoding and requires a fair amount of power. By decoding fewer instructions you save battery.

Scalable Vector Instructions in Action

If we look at the Neon instructions they encode the number of lanes used in the prefix, as shown in the previous example.

ADD v4.2D, v0.2D, v1.2D

ADD v4.4S, v0.4S, v1.4S

However if we translates this to SVE instructions, then they will look almost like this:

ADD v4.D, v0.D, v1.D

ADD v4.S, v0.S, v1.S

Meaning we no longer expose how many lanes of calculations we are performing. With SVE instructions you don’t know when compiling your code how many lanes will be used as the vector-length is unknown.

Predication

Instead the big idea in SVE is the use of what is called predication. It has a set of special registers p0 , p1 , ..., p15 which works like masks for our computational lanes. You use these to enable and disable different lanes. So the add instruction is used earlier would actually look more like this:

ADD v4.D, p0/M, v0.D, v1.D

So we got an extra argument p0/M which the CPU to only store the results of adding v0 and v1 in v4 where p0 is 1 (true), we do nothing. In pseudo code it would be something like this:

while i < N

if p0[i] == 1

v4[i] = v0[i] + v1[i]

end

i += 1

end

The predicate register also get used when e.g. loading and storing data. Here is an example of loading data from memory:

LD1D z1.D, p0/Z, [x1, x3, LSL #3]

This does a whole bunch of things so it requires some explanation. The [x1, x3, LSL #3] is typical ARM way of specifying a memory address. It can be read as something like:

base_address = x1 + x3*2^3

z1 ← memory[base_address]

But because we have the predicate, this is not entirely correct. We need to filter what gets loaded. So it is more accurately described like this:

base = x1 + x3*2^3

while i < N

if p0[i] == 1

v1[i] = memory[base + i]

else

v1[i] = 0

end

i += 1

end

This mask concept exist in many high level languages as well such as Python, R and Julia. An example in a high level language may help get the idea across. This is from the Julia command line. It should be similar in R and Python:

julia> mask = [false, true, true, false];



julia> A = [2, 4, 8, 10];



julia> B = [1, 3, 7, 9];



julia> A[mask]

2-element Vector{Int64}:

4

8



julia> B[[true, false, false, true]]

2-element Vector{Int64}:

1

9



julia> A[mask] + B[mask]

2-element Vector{Int64}:

7

15

What you see in this example is that we got vectors with four elements. We use the mask , which is similar to the predicate registers, to only pick the two middle elements. Or two middle lanes if you like.

Thus we can perform addition on only the two middle values.

How to Avoid Knowing Vector Length

Predicates is actually a generalization of if-statements for vector processing. Naturally you cannot jump around code independently for each lane. To simulate the execution of different conditions with different outcomes for each lane we use predicates.

This also helps us drastically simplify vectorized code and avoid needing to know exact length of vector. Say you got six 32-bit values to process. Basically N = 6 , and you only know this at compilation time. With Neon you would have instructions like this:

ADD v4.4S, v0.4S, v1.4S ; v4 ← v0 + v1

You can do this once, but then you got 2 elements left. If you do it twice you add up eight elements, which is too many. Thus regular vectorized code will have to do as many as it can and then have what we call a drain-loop at the end. This is where you use plain scalar operations to calculate the remainder.

With SVE, you don’t need that. Instead we got a magic instruction called WHILELT to help us. Here is an example:

WHILELT p3.s, x1, x4

But what does that do? I will explain with an pseudo-code example. Let us call the max number of lanes M . You don't know that number until runtime, but let us say M = 4 . Further we know that the number of elements we want to process is N = x4 = 6 . WHILET which is short for While Less Than works like this:

i = 0

while i < M

if x1 < x4

p3[i] = 1

else

p3[i] = 0

end

i += 1

x1 += 1

end

Thus if we imagine doing these vector operations in a loop, then on first iteration p3 will look like this:

x1 = 0

p3 = [1, 1, 1, 1]

On the second iteration however x1 will at some point not be less than x4 (our N). And so we get

p3 = [1, 1, 0, 0]

Thus there is nowhere in the code we need to explicitly specify how many lanes we are operating on. The WHILELT instruction will make sure all lanes are toggled on until we reach the end.

This is how all SIMD processing tends to work. You process batches of numbers. So e.g. if you had to process 20 elements, an your vector register was large enough to do 4 lanes at a time, then you could do five full iterations ( 5×4 = 20 ). But what if you had 22 elements instead?

You cannot do a full four-element batch at the end. Thus you need to do it manually one element at a time. With predicate registers you don’t have to do that. You just mask out the last too elements. This works when writing results back to memory. The elements which are masked by p3 don't get written back.

Gather-Scatter Load and Store Operations

Another important feature found with SVE style instructions is the support for what we call gather-scatter operations. It means you can fill up a vector register with data spread out over multiple locations in memory in just one operation. Likewise you can write results from a vector to multiple locations. The principle is similar to what we discussed with predication.

How is this useful? In higher level programming languages we usually have data stored in this fashion:

struct Sale {

int unit_price;

int sold_units;

int tax;

} Sale sales[1000];

Say we got thousands of these objects. Usually we want to do calculations between related fields. For instance you might want to multiply unit_price with the number of units sold in sold_units .That means you want one vector register will lots of unit prices and another with all the units sold. However these fields are not neatly stored in contagious chunks in memory. They are interleaved.

There are lots of little details like this which allows SVE style instructions to be applied to a much broader variety of code that you may produce. A lot more of your for-loops can be vectorized, which gives more opportunities for performance increases.

What Does SVE2 Bring to the Table?

At this point you naturally wonder what SVE2 adds that was not already in SVE?

SVE was just an optional-extension to an already established ARMv8 architecture. With SVE2 and ARMv8 it is all part of the base design. This means Neon and SVE have become much more tightly integrated. SVE has gotten added instructions which makes SVE2 basically a replacement for Neon. You can do all the stuff Neon was good at with SVE2.

Remember that SVE was originally only made for super-computing stuff, not multimedia workloads that Neon was made for. Multimedia stuff typically does not need long vector-registers. Consider something like a color pixel encoded as RGBA. It is four 8-bit values all fitting into a 32-bit register.

Each pixel is made up of four components: Red, Green, Blue and Alpha value. Each is a byte which should be calculated on separately. If a 32-bit register is a vector register with 4 components we can do that.

However with SVE2, these workloads that shorter vector-registers where well suited for, also work well with the variable length vectors of SVE2.

This gives ARM a great instruction-set which can work across their smallest and most power efficient chips up to their most performance demanding chips and users only need to compile once. Not to mention this is simply easier code to produce for a compiler. And ARM does not need to participate in this SIMD instructions arms race that Intel and AMD has been engaged in.

They will not need to add a ton of new SIMD instructions every few years. SVE2 will give them a foundation with a lot of stability and growth room.

Implications for Users, Developers and Industry

For developers this should mean writing and optimizing ARM code becomes easier. Writing machine learning, face recognition and voice recognition becomes easier. No worries about whether the target platform supports the instructions or not.

For the industry it means companies will be able to deliver a lot more diverse set of devices which utilize machine learning, whether that is cameras, tablets, smart-phones, micro-controllers or something else.

For users it means you will be less dependent on network access as your device will be able to do a lot of what the cloud had to do in the past.

ARM should also be increasingly pushing Intel and AMD out of lucrative data-center business. Now, I am no expert on chip design, but seeing how also RISC-V is pursuing this type of instruction-set and seeing all the advantages, I think Intel/AMD kind of dropped the ball on this one. Their SIMD strategy does not seem like a smart one. I suspect it will come back and haunt them.