For SVE vector length varies across the board more than it first looks:
512-bit vector len in SME/streaming mode on Apple, Qualcomm and Arm C1/C2
Shared block instead of per-core on those designs. It is worth it for some vector workloads, but worth remembering that it's a shared unit on those.
256-bit vlen on Fujitsu Monaka (out in November this year)
2x256b vector units
LineShine gets a giant vlen (and SME, without shared units) but that's a bit of a specialty chip
That's not on the open market, but #1 on the top500 with a CPU-only machine. It's twice now that CPU-only Arm machine reached #1 on the top500, with Fugaku introducing SVE and LineShine being an SVE2 + SME(1) machine.
In the standard library I'd love to see crater-like verification of changes to intrinsics, and std::simd available on stable so that ecosystem crates would delete most of their code and gain support for all the obscure platforms.
Considering the level of detail about Intel, etc., that part (which I find the most important) is lacking the author’s view of how to get there.
never_released | 10 hours ago
For SVE vector length varies across the board more than it first looks:
Shared block instead of per-core on those designs. It is worth it for some vector workloads, but worth remembering that it's a shared unit on those.
2x256b vector units
That's not on the open market, but #1 on the top500 with a CPU-only machine. It's twice now that CPU-only Arm machine reached #1 on the top500, with Fugaku introducing SVE and LineShine being an SVE2 + SME(1) machine.
hsivonen | 5 hours ago
Considering the level of detail about Intel, etc., that part (which I find the most important) is lacking the author’s view of how to get there.
mperham | 2 hours ago
Related: the state of SIMD in Go. https://go.dev/blog/simd-experiment