Go可移植SIMD实践

一份 Go SIMD 代码跑在 x86 和 ARM 上，新实验性 simd 包值得用吗？

如果一段字节处理代码要同时跑在 x86 服务器和 ARM 机器上，手写两套向量实现很容易把优化变成维护任务。Go 1.27 新增的实验性 simd 包给了另一种写法，让代码使用长度未指定的向量，由实现去选择硬件指令或纯 Go 模拟。这个承诺值得试，但是否值得放进项目，仍要看具体任务和基准结果。

先把例子缩到一行灰度像素

下面只做一件事，把灰度图每个像素增加 20，超过 255 就停在 255。输入和输出都是 []byte，不讨论解码、行跨度或颜色空间。普通循环的语义很直白，也方便作为正确性基线。

func brightenScalar(dst, src []byte) {
for i, v := range src {
n := int(v) + 20
if n > 255 { n = 255 }
dst[i] = byte(n)
}
}

可移植 SIMD 版本使用 Uint8s 的饱和加法。LoadUint8s 读取一个完整向量，AddSaturated 保证每个字节相加后不回绕，Store 写回。向量一次容纳多少个字节由 x.Len() 给出，代码不把宽度写死。末尾不够一个向量的字节继续走普通循环，这也避免了补零、部分写入和边界语义混在一起。两个函数都要求 dst 至少与 src 等长，调用处应先检查。

func brightenSIMD(dst, src []byte) {
step := simd.BroadcastUint8s(0).Len()
add := simd.BroadcastUint8s(20)
i := 0
for ; i+step <= len(src); i += step {
simd.LoadUint8s(src[i:i+step]).
AddSaturated(add).Store(dst[i:i+step])
}
for ; i < len(src); i++ {
n := int(src[i]) + 20
if n > 255 { n = 255 }
dst[i] = byte(n)
}
}

示例需要 import "simd"，并在构建时设置 GOEXPERIMENT=simd。这个开关不是运行时参数，漏掉它就不能按普通标准库包来使用。官方文档还说明，可移植 simd 在所有架构可用，向量至少 128 位，硬件支持时使用硬件实现，否则可能由纯 Go 模拟。因此“同一份源码能构建”不等于“每台机器都会提速”。实际部署前还要记录 simd.Emulated() 和 simd.VectorBitSize()，免得把模拟路径的数字误读成硬件 SIMD 的效果。

可移植和架构专属的边界

Go 1.26 已开始提供实验性的 simd/archsimd。到 Go 1.27，官方说明修订了 amd64 API，增加 arm64 Neon 的 128 位支持，也覆盖 WebAssembly 的 128 位向量；部分 amd64 处理器可用 256 位或 512 位类型。它暴露的是特定架构的类型和操作，适合需要精确控制指令与向量宽度的代码，代价是要按架构组织实现和构建条件。

新 simd 包的接口更窄，提供跨架构容易实现的一部分操作。这里的饱和加法刚好落在这部分内，省去了自己维护 amd64 与 arm64 两份代码。若算法依赖某条架构指令，或者需要手动选择 128 位、256 位实现，就不能期待可移植层替你表达全部细节。两套 API 都通过 GOEXPERIMENT=simd 开启，目前仍属实验性，升级工具链时要重新编译和复测；包文档和发布说明都应作为版本依据。

基准怎样测才算公平

先做单元测试。输入长度至少覆盖 0、1、向量宽度前后、几倍向量宽度再多一个字节；像素值包含 0、234、235、255，并随机填充其余位置。每组输入分别运行两个函数，逐字节比输出，同时检查源切片未被改动。若输出允许与输入同一底层数组重叠，还要单独测原地处理；本文示例只以不重叠的 src 和 dst 为约定。

性能测试要把初始化移出计时区，两种实现复用同样大小、同样内容的输入输出缓冲区，避免把分配和随机数生成算进某一方。建议分别用 32 B、4 KiB、1 MiB 等规模，观察短输入的固定开销和大输入的内存带宽影响。每轮运行后消费一个输出字节以防结果被忽略，并用 b.SetBytes(len(src)) 报告吞吐。两个 benchmark 写在同一测试文件，单线程先跑，再按真实服务并发度补测。

# Linux/macOS shell
GOEXPERIMENT=simd go test -run '^TestBrighten$' ./...
GOEXPERIMENT=simd go test -run '^$' -bench 'Brighten' \
-benchmem -benchtime=2s -count=10 ./...

# Windows PowerShell
$env:GOEXPERIMENT='simd'
go test -run '^TestBrighten$' ./...
go test -run '^$' -bench 'Brighten' -benchmem -benchtime=2s -count=10 ./...

记录 go version、GOOS、GOARCH、CPU 型号、实际频率策略、simd.Emulated()、simd.VectorBitSize()，并固定 Go 版本、输入数据与运行条件。x86 和 ARM 分别在各自机器上运行，不把两台机器的绝对 ns/op 当作 SIMD 优劣的证据。看同一台机器上 scalar 与 SIMD 的配对结果，最好用 benchstat 汇总十轮分布；如果差距落在波动范围内，就写没有可靠差异。还可以检查编译产物的反汇编，确认热点路径是否真的用了预期指令，但这不能替代端到端基准。

我会在什么情况下用它

这段代码最顺手的地方是 AddSaturated 直接对应需求，不用先写溢出判断。让人停一下的地方则是向量宽度不能当常量来想，尾部必须认真处理，实验开关也要进入构建与发布流程。若输入常常只有几十字节，或者普通循环已经足够快，我会先保留循环。它少一个实验依赖，读者也更容易确认边界行为。

若同一段热路径确实在 x86 与 ARM 上运行，数据量足够大，而且两端的同机对照都显示稳定收益，可移植 simd 才值得进入候选实现。届时仍应保留普通循环作为对照和回退路径，并让性能回归测试跟着工具链升级走。现在能下的判断只到这里。官方 API 说明了能怎样写，速度要由目标机器回答。

参考资料

Go 1.27 Release Notes，New experimental simd package 与 Experimental simd/archsimd package。https://go.dev/doc/go1.27

Go package simd 文档，向量长度、LoadUint8s、AddSaturated、Emulated 与 VectorBitSize。https://pkg.go.dev/simd

Go package simd/archsimd 文档。https://pkg.go.dev/simd/archsimd

Go testing 包文档，Benchmark、SetBytes 与计时接口。https://pkg.go.dev/testing