Go 1.27 adds a portable SIMD package that hides vector widths from 128 to 2048 bits
Victoria Shinder2 min readGo 1.26 shipped an experimental SIMD API for amd64, and Go 1.27 extends it to arm64 NEON and to wasm. Both live in an architecture-dependent archsimd package, which is the honest place for them: the platforms differ not only in which operations exist but in how a vector is represented at all. Some fix the width at build time, others leave it to be queried when the program starts.
Go 1.27 adds a second, fully portable interface on top, a simd package modelled loosely on the Highway library for C++. It currently supports AVX, AVX2 and AVX512 on amd64, NEON on arm64, and the wasm SIMD instructions, and the stated goal is write-once code that stays near assembly speed where vector units exist and falls back to a competent emulation where they do not.
The post is unusually direct about what the portable layer has to absorb. Fixed widths of 128 bits on wasm, PowerPC and s390x; three widths on amd64; riscv64 with anything between 128 and 65536 bits as long as it is a power of two; arm64 with NEON at 128 and SVE from 128 to 2048. Masking differs the same way: AVX512 and RVV have dedicated mask registers with one bit per element, while wasm, AVX, AVX2 and NEON have no masks and emulate them with vector bitmasks.
What it means
Before this, reaching the vector units from Go meant writing Go assembly, which is worth doing for a handful of hot kernels and nowhere else. The practical effect was not that Go programs were slow, it was that most of them silently left a large part of the CPU unused because the cost of the only available route was too high for ordinary code.
The interesting decision is keeping both packages. A portable API that quietly loses AVX512 masking would be worse than none, because the performance would be plausible and the ceiling invisible. Having archsimd underneath means the portable layer can be judged on what it is for — the code you would otherwise write in scalar Go — rather than being asked to stand in for hand-tuned kernels. Both are experimental, so the thing to watch in the next cycle is not the benchmark numbers but which of the two people actually reach for.