The capabilities of various SIMD ISAs don't have enough intersection to be portable outside of relatively trivial cases. Many of the somewhat unique capabilities are load-bearing, so you want to use them on architectures that support them. Taken in whole, someone who cares about performance would be using different data structures and algorithms depending on the specific SIMD architecture and that is nearly impossible to abstract in a library. Too many important but complex details are idiosyncratic to the implementation.

Another way of looking at it is that our programming environments are not sufficiently powerful and expressive to create the necessary abstractions to make SIMD truly portable.

It should really be read/advertised as "portabler SIMD". It beats hoping the compiler autovectorizes everything well forever or writing architecture specific code manually again but is going to compromise on average performance vs platform specific SIMD.

> They specifies a constant SIMD width so it's non-portable.

This is incorrect, you can use vectors wider than native SIMD width and the compiler will break them down to register size of the target cpu.

In fact it's sometimes better to used wider than native width, in some applications I see 20% better throughput with f32x16 (512 bits) on an AVX2 CPU (256 bits). It is kinda like loop unrolling it.

Go's implementation is vector size independant https://pkg.go.dev/simd@master

Why should it be portable? Honest question.

SIMD seems to me, to be very platform specific. Maybe there are times one SIMD unit is not anothers' SIMD unit?