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 a

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 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.