I'm just happy that finally, with the popularity of zen4 and 5 chips, AVX512 is around ~20% of the running hardware in the steam hardware survey. It's going to be a long while before it gets to a majority - Intel still isn't shipping its own instruction set in consumer CPUs - but its going the right direction.<p>Compared to the weird, lumpy lego set of avx1/2, avx512 is quite enjoyable to write with, and still has some fun instructions that deliver more than just twice the width.<p>Personal example: The double width byte shuffles (_mm512_permutex2var_epi8) that takes 128 bytes as input in two registers. I had a critical inner loop that uses a 256 byte lookup table; running an upper/lower double-shuffle and blending them essentially pops out 64 answers a cycle from the lookup table on zen5 (which has two shuffle units), which is pretty incredible, and on its own produced a global 4x speedup for the kernel as a whole.
When I optimize stuff, I just think of the SIMD instructions as a long sandwich toaster. You can have a normal toaster that makes one sandwich, or you can have a 4x toaster that makes 4 sandwiches as once. If you have a bunch of sandwiches to make, obviously you want to align your work so that you can do 4 at a time.<p>If you want to make 4 at a time though, you have to keep the thing fed. You need your ingredients in the cache, or you are just going to waste time finding them.
Compared to GPU programming the gains from SIMD are limited but it's a small-multiple boost and available pretty much everywhere. C# makes it easy to use through Vector classes. WASM SIMD still has a way to go but even with the current 128-bit you can see dramatic improvements in some buffer-processing cases (I did a little comparison demo here showing a 20x improvement in bitwise complement of a large buffer: <a href="https://www.jasonthorsness.com/2" rel="nofollow">https://www.jasonthorsness.com/2</a>)
> a small-multiple boost<p>Quick reminder that a 20x boost is better than going from O(n) to O(log n) for up to a million items. And, that log n algorithms often are simply not possible for many problems.
The high arithmetic bandwidth on GPUs is of course SIMD based as well. They just tend to have a ISPC style compilation model that doesn't expose the SIMD lanes in the source code. (Whereas SIMD even after decades is very lightly utilized by compilers on the CPU side).
The WASM folks should just include an arbitrary-length vector compute extension. We should also explore automatically compiling WASM to GPU compute as appropriate, the hardware independence makes it a rather natural fit for that.
I merged a few PRs to SIMD optimize Wasm WASI libc, but it all got stalled in str(c)spn (which is slightly more sophisticated than the rest).<p>There wasn't much appetite for any of it on Emscripten.<p><a href="https://github.com/WebAssembly/wasi-libc/pulls?q=is%3Apr+optional+simd" rel="nofollow">https://github.com/WebAssembly/wasi-libc/pulls?q=is%3Apr+opt...</a>
4 lanes of SIMD (like in say SSE) is not necessarily 4x faster because of the memory access, sometimes it's better than that (and often it's less).<p>PSHUFB wins in case of unpredictable access patterns. Though I don't remember how much it typically wins.<p>PMOVMSKB can replace several conditionals (up to 16 in SSE2 for byte operands) with only one, winning in terms of branch prediction.<p>PMADDWD is in SSE2, and does 8 byte multiplies not 4.
SSE4.1 FP rounding that doesn't require changing the rounding mode, etc.
The weird string functions in SSE4.2. Non-temporal moves and prefetching in some cases.<p>The cool thing with SIMD is that it's a lot less stress for the CPU access prediction and branch prediction, not only ALU. So when you optimize it will help unrelated parts of your code to go faster.
The main problem with SIMD instructions is that regular code doesn't use them. Almost always someone need to write SIMD code manually to achieve good performance, which is rarely done and if so, only in some tight loops and niche cases. Like cryptography-related code in a browser may be SIMD-based, but other code uses almost no SIMD.<p>Modern compilers are able sometimes to vectorize regular code, but this is done only occasionally, since compilers can't often prove that read/write operations will access valid memory regions. So one still needs to write his code in such a way that compiler can vectorize it, but such approach isn't reliable and it's better to use SIMD instruction directly to be sure.
Related: Go is looking to add SIMD intrinsics, which should provide a more elegant way to use SIMD instructions from Go code: <a href="https://go.dev/issue/73787" rel="nofollow">https://go.dev/issue/73787</a>
The author has neglected the 3DNow! SIMD instructions from AMD.<p>They were notable for several reasons, although they are no longer included in modern silicon.<p><a href="https://en.wikipedia.org/wiki/3DNow" rel="nofollow">https://en.wikipedia.org/wiki/3DNow</a>!
Wider SIMD would be useful, especially with AVX-512 style improvements. 1024 or even 2048 bits wide operations.<p>Of course memory bandwidth should increase proportionally otherwise the cores might have no data to process.
I wouldn't mind, but might need to increase cache line size on x86, as avx512 has reached the current size.
Much better to burn the area for multiple smaller units, its a bit more area for frontend handling, but worth it for the flexibility (see Apple's M-series chips vs intel avx*).
Yes and no. I think neon is undersized for today at 128bit registers -- if you're working with doubles for example, that's only two values per register, which is pretty anemic. Things like shuffles and other tricky bitops benefit from wider widths as well (see my other reply)
Agreed that 128 bit is undersized, but 512 feels pretty good for the time being. We're unlikely to see further size increases since going to 1024 would require doubling the cache line, register file, and ram bandwidth, while just adding an extra fma port is far less hardware.
totally - especially given how bandwidth constrained CPUs still are, going wider than 512 doesn't make much sense. 512 itself was a stretch for quite a long time (and all the negative press on the original implementations was a consequence of being not-quite-ready for primetime), but for current hardware I think it's perfect.<p>But 128bit is just ancient. If you're going to go to significant trouble to rewrite your code in SIMD, you want to at least get a decent perf return on investment!
I would love to be able to fit small matrices (4x4 or 16x16 depending on precision) in SIMD registers together with intrinsics for matrix arithmetic.
AMX registers are 1024 *bytes*
This would start looking a lot like a GPU.
Recent and related:<p><i>Why do we even need SIMD instructions?</i> - <a href="https://news.ycombinator.com/item?id=44850991">https://news.ycombinator.com/item?id=44850991</a> - Aug 2025 (8 comments)
No mention of branches, which is a complementary concept. If you unwind your loop, you can get part of the way to SIMD performance by keeping the CPU pipeline filled.
Why does such an abbreviation still exist in 2025?<p>They have been in the CPUs for so long that I expected them to be inseparable to the degree that people wouldn't even remember they were a separate thing in the past.