Go 平台无关 SIMD API 与架构专用 API 怎么选

如果你的 Go 代码要同时跑在 amd64、arm64 和 wasm，默认先看平台无关的 simd；如果热点只服务一种架构，而且确实需要某条指令、某个向量宽度或公共接口没有覆盖的操作，再评估 simd/archsimd。两者都属于实验性能力，不能把“能编译”直接等同于“值得上线”。

官方资料：https://go.dev/blog/simd-experiment

下面的判断只针对 Go 1.27 这组实验性 API：先看部署约束，再看操作覆盖，最后用标量基线和基准数据决定是否保留 SIMD。

先看两套 API 的定位

simd 隐藏了固定向量宽度，使用类似 simd.Float32s 的类型，并从切片加载和存储数据。它只承诺不同平台的公共能力，缺口则尽量用其他 SIMD 指令或软件仿真补齐，因此代码更容易跨平台。

simd/archsimd 则把架构差异暴露出来。Go 1.26 先提供 amd64 方向，Go 1.27 又扩展到 arm64 NEON 和 wasm；它适合需要观察特性、向量尺寸和指令差异的内层热点，但也意味着你要维护平台分支。

按约束做选择

可以把选择压缩成四个问题：

• 部署范围：跨 CPU、容器节点或 wasm，优先 simd；单一硬件环境才有理由深入 archsimd。
• 操作需求：加减、比较、加载、存储等公共操作适合平台无关接口；如果算法依赖某个架构专有指令，平台无关接口可能没有等价方法。
• 向量宽度：不希望业务代码感知 128、256、512 位时选 simd；必须针对宽度调参时才接受架构耦合。
• 回退要求：平台无关接口在没有硬件 SIMD 时也能运行；架构专用实现则要准备构建约束、替代实现和测试矩阵。

因此，跨平台数据处理库通常先把算法写成 simd，再把少数没有公共表达的操作拆到架构专用文件中。官方文章也给出了通过 ToArch() 和对应的 FromArch 在两者之间转换的方向，但这会把每个平台的实现责任重新带回项目。

一个可控的起点：先写平台无关内积

下面的代码展示选择 simd 后的基本形状。注释说明了实验开关、按向量长度推进以及尾部元素处理；它是写法示意，不代表在当前机器上已经得到某个性能数字。

//go:build goexperiment.simd

package dot

import "simd"

// InnerProduct 计算两个等长切片的内积；主体不依赖固定向量宽度。
func InnerProduct(x, y []float32) float32 {
	var acc simd.Float32s
	width := acc.Len() // 由当前 SIMD 实现决定，不把 128/256/512 写死。
	var i int
	for ; i+width <= len(x); i += width {
		// Load 读取一整组元素，MulAdd 把乘积累加到向量寄存器。
		a := simd.LoadFloat32s(x[i : i+width])
		b := simd.LoadFloat32s(y[i : i+width])
		acc = a.MulAdd(b, acc)
	}
	// 尾部不足一个向量时使用 Part 版本，避免切片越界。
	if i < len(x) {
		a, _ := simd.LoadFloat32sPart(x[i:])
		b, _ := simd.LoadFloat32sPart(y[i:])
		acc = a.MulAdd(b, acc)
	}
	return reduceScalar(acc) // Go 1.27 可用标量归约；后续版本可用更高层归约 API。
}

// reduceScalar 把向量暂存到切片后求和，明确处理当前向量长度。
func reduceScalar(v simd.Float32s) float32 {
	values := make([]float32, v.Len())
	v.Store(values) // Store 只负责落盘，求和仍由普通 Go 代码完成。
	var total float32
	for _, value := range values {
		total += value
	}
	return total
}

构建时需要显式打开实验能力：GOEXPERIMENT=simd go test ./...。如果你的发布环境不能接受实验性 API，标量实现应该保留为默认路径，而不是把整个项目绑定到实验包。

什么时候应该转向 archsimd

有三种情况值得考虑架构专用 API：第一，基准已经证明公共 simd 路径是瓶颈；第二，算法需要公共交集之外的操作；第三，部署目标固定，团队能承担多套构建和测试。此时应把架构相关代码隔离在小接口后面，让上层只看到普通 Go 函数。

不要仅因为服务器支持 AVX2 就切换。不同机器可能支持不同特性，Go 提供的 GODEBUG=simd=0 可帮助测试仿真路径，GODEBUG=simd=128、256 或 512 可用于检验向量级别；这些设置是实验 API 的诊断手段，不是性能承诺。

最终决策表

一句话总结：把 simd 当成跨平台算法层，把 archsimd 当成经过测量后才启用的硬件特化层；两者之间的边界，应该由部署范围、操作需求和基准结果共同决定。

相关问题

Go 的 simd API 已经稳定了吗？

没有。官方资料将它们定位为实验性 API，构建和接口都可能继续变化，应锁定 Go 版本并保留替代路径。

没有 SIMD 指令的机器能运行平台无关代码吗？

可以，平台无关接口会使用软件仿真；但是否足够快要以你的数据规模和基准为准。