Go 1.27 ships a size-agnostic simd package for loops that once needed per-architecture assembly

The obstacle to a single SIMD API in Go is the vector itself. On wasm, PowerPC and s390x a vector is 128 bits, amd64 offers 128, 256 and 512, and loong64 offers 128 and 256 ^[7]. Riscv64 allows any power of two from 128 to 65536 bits. Arm64 pairs fixed 128-bit NEON with SVE at 128 to 2048 bits ^[8]. On some platforms the size is unknown at build time and has to be queried when the program starts ^[9].

Masking is worse. Wasm, AVX, AVX2 and NEON have no mask registers, so masking is done with vector bitmasks and boolean operations ^[10]. AVX512 and RVV have mask registers with one bit per element ^[10]. SVE allocates one bit per vector byte and reads the least-significant bit of each element's group. AVX2's masked loads and stores take a plain vector and read the most-significant bit ^[11]. Wasm also has no comparison for vectors of 64-bit integers ^[12].

The archsimd package leaves many of those quirks visible. The Go team wrote that they make designing, writing and testing multiplatform SIMD code "onerous" ^[13]. After the masking rules, that word seems restrained. The team also wrote that archsimd could be made more uniform, "but we can only go so far without compromising efficiency" ^[13]. The portable simd package takes the other path and removes fixed-size vectors from the type system ^[14]. A kernel's types no longer commit it to 128 or 512 bits ^[14].

That portability changes what a benchmark number means. A 512-bit AVX-512 vector holds 8 float64 values, the post's own example of what one instruction can add. A 128-bit NEON vector holds 2 [c18, c19]. So the same source can process four times as many elements per instruction on one machine as on another ^[18]. An amd64 speedup carries over to arm64 only if the loop is limited by something other than vector width, such as memory bandwidth or a scalar tail.

Where the package has no hardware backend, it emulates vectors, and the post calls that emulation "competent" ^[6]. The supported list is AVX, AVX2 and AVX512 on amd64, NEON on arm64, and wasm's SIMD instructions ^[5]. Riscv64, loong64, PowerPC and s390x all appear in the post's own survey of SIMD architectures, and they run on emulation for now ^[20]. On arm64 the package uses NEON's fixed 128 bits, and SVE's wider vectors are not yet supported [c5, c8].

I think the two-package split is the right design. Archsimd keeps each platform's instructions reachable for the kernels that need a specific one, and simd covers the common loop [c3, c14]. For a service that runs on both amd64 and arm64, I would write the portable kernel first and benchmark it on each fleet. Assembly would stay only for a loop where the numbers show the portable version falls short.