Arm Updates Its Neoverse Roadmap: New BFloat16, SVE Support | Hacker News Reader

Arm Updates Its Neoverse Roadmap: New BFloat16, SVE Support

fuse.wikichip.org

41 pointsrbanffy13 comments

I was quite skeptical about SVE, but it seems Fujitsu A64FX proved it works.

Now I wonder if vector processing works (in terms of hardware implementation), why the market was dominated by SIMD for a while, since being vector length agnostic is clearly better for software.

Given that it's multiples of 128-bits, perhaps the cost of doing SVE requires some threshold to be crossed before it's effective?

I think it was just a matter of evolutionary steps. The P5 had two 32bit ALU pipes, and a bank of 64bit registers for the FPU, so MMX was a relatively modest extension attop them to support 64bit wide short vector SIMD. SSE switched to using dedicated registers and wider widths, but was an evolutionary improvement.

I'm pretty curious whether Arm SVE, or the similar design in RISC-V, will pressure x86 into a similar extension. The vector length agnostic binary support is certainly compelling.

SVE seems pretty interesting. I'd like to see how a bunch of tiny, in-order chips with very wide vector units could compete with GPU designs as CPU and GPU designs seem to be slowly converging.

Can anyone explain to me the benefits of sve over the old stuff?

Edit: intel had some issues with wider simd, is SVE affected by the same issues?

A few of the issues:

1) Not much code is written to take advantage of them. This seems like inherently less of a problem with SVE, assuming it becomes widely adopted, as this should naturally support compiling source to take advantage of whatever the vector width of the host CPU happens to be. In the same vein, SVE easily supports market segmentation without the instruction set extension fragmentation that's been causing problems for Intel.

The Arm SIMD Implementations lists the following SVE cpus:

  - Neoverse N2 (2x 128 bit units, comparable to Atom w/ SSE only)
  - Neoverse V1 (2x 256 bit units, comparable to AMD's offerings and Intel's desktop offering, w/ AVX2)
  - A64FX (2x 512 bit, comparable to Intel server and HEDT with AVX512 [not all of which have 2x fma units]).

For the x86_64 CPUs, you'd need three binaries or function multiversioning to support them all and make the most of the hardware. With ARM, you could do it with a single ordinarily compiled binary.

2) Downclocking, already mostly solved on Ice Lake: https://news.ycombinator.com/item?id=24215022 Using more of the chip will obviously use more power, so of course you'll have to hit thermal or power limits sooner. But wider units are more efficient, so you'll get more work done before hitting such limits; the problematic downclocking was where a handful of such instructions would trigger it, out of proportion of energy requirements.

3) Not all workloads can benefit from wide SIMD units. Some people (famously Linus Torvalds) would be much better off and happier with using the space for more cores.

As for benefits, if you like HPC-like workloads (numerics that are hard to offload to the GPU), wide SIMD units on the CPU can be an excellent way to accelerate it. This benefits that audience most.

SVE doesn't really solve #2 and #3 by itself. You can still design a core with huge SIMD units that require a ton of power and area, resulting in downclocking and relatively poor performance on non-SIMD workloads.

#1 is a big deal though. It's a huge burden to rewrite SIMD code over and over for every new instruction set, so people (and compiler implementers) just don't use it too often. Then you're paying power and die area for completely useless SIMD units.

I don't understand how #1 is possible. How do you statically compile the code once & have it automatically choose the right vector width that's available on the CPU at run time? Does the compiler just emit an instruction saying "ideal width at this point is 256bits" & the CPU will automatically optimize that however needed?

I've been unable to find any meaningful description of how this actually works.

An example showing how one writes vector-length agnostic code using C intrinsics, and the assembly that is produced:

https://developer.arm.com/documentation/100891/0612/coding-c...

Could just be me, but that seems mind-bogglingly complex vs regular vector instructions & could easily make some traditional programs even harder to vectorize.

Aside from the variable lengths which are really neat, SVE supports AVX512 style masking (predicates), which makes some algorithms simpler and hopefully faster

Is there a point where a CPU stops being RISC and starts being CISC, or are there fundamental differences in the two?

The key distinction is addressing modes usable in instructions. Even RISC architectures that spiral into complexity tend to keep the basic separation of LOAD/STORE vs other instructions, while CISC almost always allows flexible arguments of registers, immediates, or a variety of memory address expressions to be used with most instructions.

Reply on news.ycombinator.com