Go SIMD API 怎么为不同架构保留同一套向量代码

Go SIMD API 要跨 amd64、arm64 和 wasm 保留同一套向量代码，关键不是把每个平台的寄存器类型改成同一个名字，而是让业务循环只依赖实验性的 simd 包：向量长度由运行环境决定，硬件没有对应指令时由 Go 模拟。构建时开启 GOEXPERIMENT=simd，并把架构特有能力收拢到单独适配层。

先把固定向量宽度从业务代码里拿掉

simd/archsimd 适合需要 AVX、NEON 等专属指令的底层代码，但它的类型会带有架构和形状信息。要让同一份算法覆盖不同机器，应从 simd 包导入向量类型。Go 1.27 的实验性接口支持 amd64 的 AVX 系列、arm64 的 NEON 和 wasm SIMD；未覆盖的平台仍可以使用模拟实现。

生产代码需要显式接受实验性边界：把开关写进构建脚本，并在 CI 中固定 Go 版本。下面的示例计算两个切片的点积，循环步长来自当前向量的 Len()，没有假设一组向量一定装下多少个元素。

package dot

import "simd"

// Dot 计算两个等长切片的点积；向量宽度由当前架构决定。
func Dot(x, y []float32) float32 {
	if len(x) != len(y) {
		panic("dot: length mismatch") // 先拒绝不一致输入，避免静默截断。
	}
	var acc simd.Float32s
	width := acc.Len()
	i := 0
	for ; i+width 

尾段、模拟路径和构建开关要一起验证

这类代码最容易在尾段出错。循环只处理完整向量，最后不足 Len() 的数据交给 LoadFloat32sPart；它返回部分有效元素数量，示例中由于补零向量参与乘加，结果仍然只包含输入尾段的贡献。

把下面的命令加入 CI 的实验性 SIMD 作业。GODEBUG=simd=0 强制模拟路径，适合检查算法是否依赖某个硬件指令；GOARCH 则负责做目标架构的编译检查。wasm 的执行还需要对应 WASI 运行时，不能把交叉编译成功误认为运行成功。

# 开启实验性 simd API，先执行包测试。
GOEXPERIMENT=simd go test ./...

# 强制纯 Go 模拟路径，检查尾段和归约结果。
GODEBUG=simd=0 GOEXPERIMENT=simd go test ./...

# 只做目标架构编译检查；不要把它当成目标机运行测试。
GOEXPERIMENT=simd GOOS=linux GOARCH=arm64 go test -run '^$' ./...
GOEXPERIMENT=simd GOOS=wasip1 GOARCH=wasm go test -run '^$' ./...

测试数据至少要覆盖空切片、长度为 Len()-1、恰好为 Len()、以及跨越两个向量的长度。性能比较则固定输入、编译参数和基准环境，同时保留标量实现；SIMD 加速只对计算占比高、数据量足够大的内层循环有意义。

公共交集不够时，再隔离 archsimd 特化

simd 只承诺跨平台公共能力。如果算法确实需要某个平台没有的操作，可以把向量用 ToArch() 转成 any，再断言为对应的 archsimd 类型，最后用相应的 FromArch 转回。这个选择会重新引入架构分支：每个目标平台都要有实现或模拟方案，因此不应把转换散落到业务循环。

常见问题

为什么不直接把向量类型写成 Float32x4？

固定形状会把实现绑定到某种架构或向量宽度，arm64、wasm 和未来的可伸缩向量无法复用同一循环。跨平台层应使用无宽度类型。

GODEBUG=simd=0 适合生产环境吗？

它主要用于回归和故障隔离。生产是否强制模拟要由性能基准决定，通常应让运行时选择可用硬件。

交叉编译通过就代表 SIMD 可用吗？

不代表。交叉编译只能证明目标代码能生成；还要在目标环境或对应运行时执行测试，并确认目标 CPU 的指令能力。

Go SIMD 的可移植写法可以概括为：业务算法依赖 simd 公共交集，循环用运行时向量长度推进，尾段用部分加载收口，平台专属操作留在边界层。这样既保留硬件加速，也不会把整套代码锁死在单一架构上。