simd包编写跨架构向量运算

如果目标是让同一段 Go 向量运算在 amd64、arm64 等架构上保持相同的调用方式，Go 1.27 的实验性 simd 包比直接使用 simd/archsimd 更适合作为应用层入口。它提供向量长度无关的类型：支持硬件 SIMD 时走对应后端，不支持时使用纯 Go 模拟；调用方只处理切片和向量方法，不把 AVX、Neon 或具体寄存器宽度写进业务 API。

官方资料：https://pkg.go.dev/simd@go1.27.4

simd 先解决什么问题：统一向量 API，隐藏硬件宽度

SIMD 的难点不只是把标量循环改成向量加法。不同架构的向量寄存器宽度、指令集合和掩码表示并不相同，直接把架构专用类型放进业务包，会让公共函数签名跟着硬件变化。Go 官方的设计采用两层思路：高层 simd 负责可移植的向量抽象，低层 simd/archsimd 供确实需要架构指令的代码使用。

当前高层包的向量长度在一次程序运行中保持一致，具体长度由实现选择；它可以在支持的硬件上使用 SIMD，也可以退回纯 Go 模拟。因此跨架构代码的边界应该放在普通切片上：

package vector

import "simd"

// AddFloat32 只把普通切片作为公共输入，避免暴露架构专用向量类型。
func AddFloat32(a, b []float32) []float32 {
	if len(a) != len(b) {
		panic("vector length mismatch") // 业务层也可以改成返回 error。
	}
	out := make([]float32, len(a))
	for i := 0; i 

这个结构的关键不是“永远更快”，而是把向量宽度留给实现层决定。调用方只需要保证两个输入切片等长，并让 Part 方法处理尾部。图中的分组关系是静态说明图，不代表某台机器已经执行出某个结果。

触发信号：为什么直接写 archsimd 会让跨架构变难

如果代码一开始就使用 simd/archsimd，通常会遇到三个触发信号：类型名带着 Float32x4 或 Float64x8 等固定宽度；源码只能在指定架构上编译；上线后还要自己判断 AVX、AVX2 或其他 CPU 特性。官方文档明确说明，archsimd 是架构相关的低层包，当前可用类型与操作依赖目标架构，也不建议把这些类型暴露在公共 API 中。

因此判断很直接：

处理步骤：用 Part API 写出不依赖宽度的循环

LoadFloat32sPart 会从切片加载当前实现能处理的元素，不足部分补零并返回实际加载数量；StorePart 把结果写回目标切片并返回实际写入数量。循环推进应使用返回值，而不是自己猜“每次四个”或“每次八个”。这样同一份代码可以面对不同向量长度，也不会在最后一小段数据上越界。

如果你需要把结果交给异步任务，仍然按普通切片的所有权规则处理：先确认输出切片由调用方拥有，再交给队列或 goroutine。SIMD 只改变计算表示，不改变 Go 切片的生命周期、边界和数据竞争规则。

func AddFloat32Checked(a, b []float32) ([]float32, error) {
	// 先检查业务长度，避免把错误带进向量加载阶段。
	if len(a) != len(b) {
		return nil, fmt.Errorf("length mismatch: %d != %d", len(a), len(b))
	}
	out := make([]float32, len(a))
	for i := 0; i 

上面的第二个片段需要在文件导入区加入 fmt 和 simd。示例刻意保留了错误返回和尾部处理；工程代码还应根据项目约定决定是否允许输入为空，以及是否要为热点循环增加独立基准。

跨架构发布时，构建选择和运行状态要分开看

simd 和 simd/archsimd 属于实验性能力，构建时需要打开 GOEXPERIMENT=simd。目标架构由 GOARCH 决定；这两个变量解决的是“编译哪一套代码”，而 Emulated 与 VectorBitSize 解决的是“当前进程实际选择了什么实现”。不要把交叉编译成功误认为目标机器一定会使用硬件向量路径。

# 为目标架构构建，实验开关必须和构建命令一起传入。
GOEXPERIMENT=simd GOOS=linux GOARCH=amd64 go build ./...
GOEXPERIMENT=simd GOOS=linux GOARCH=arm64 go build ./...

# 运行时只记录实现状态，不把它当成业务正确性的前置条件。
GOEXPERIMENT=simd go test ./...

应用启动时可以把实现状态写入诊断信息：

func SIMDStatus() string {
	// Emulated 为 true 时表示没有使用实际硬件向量实现。
	mode := "hardware"
	if simd.Emulated() {
		mode = "pure-go-emulation"
	}
	return fmt.Sprintf("mode=%s vector_bits=%d", mode, simd.VectorBitSize())
}

这条信息适合进入启动日志或诊断端点，但不要用它替代功能测试。不同机器可能具备不同的指令集，性能结论要在目标硬件上单独测量；若目标不适合实验性包，则保留普通 Go 实现作为发布回退。

回滚路径：把 SIMD 当成可替换的性能层

出现以下情况时，应把向量层降级为普通 Go 循环或暂时关闭实验能力：目标工具链不支持 GOEXPERIMENT=simd；依赖的向量方法在目标架构上不可用；基准显示数据规模太小，向量装载成本抵消了收益；或者实验性 API 的变更风险超过当前版本的收益。

最稳妥的包结构是让业务层依赖 AddFloat32 这样的普通切片函数，SIMD 只存在于函数内部。这样回滚只替换内部实现，不需要修改调用方，也不会把 archsimd 类型扩散到整个项目。对外 API 尽量使用切片、标量和错误值，对内再选择硬件或模拟路径。

发布前清单：确认的是边界，不是某个固定数字

• 是否打开了与目标 Go 版本匹配的 GOEXPERIMENT=simd，并分别为目标 GOARCH 构建？
• 是否使用 LoadPart、StorePart 或等价逻辑覆盖空切片和尾部数据？
• 是否没有在公共 API、持久化结构或跨包接口中暴露 simd/archsimd 类型？
• 是否把 simd.Emulated() 和 simd.VectorBitSize() 当作诊断信息，而不是功能正确性的判断条件？
• 是否准备了普通 Go 回退，并在目标硬件上独立测量收益？

常见问题

simd 包是不是只支持 amd64？

高层 simd 的目标是跨架构和向量长度无关；官方文档列出硬件实现与纯 Go 模拟两类路径。具体架构、方法和实验版本仍应以当前工具链的包文档为准。

为什么不能直接把 simd.Float32s 放进公共结构体？

虽然高层类型比 archsimd 更可移植，但它仍属于实验性能力，而且向量长度由实现决定。公共业务接口使用普通切片更容易兼容回退和未来 API 变化。

Emulated 为 false 就一定比普通循环快吗？

不一定。它只说明使用了硬件向量实现，实际收益还取决于数据规模、内存访问、分支和调用边界，应该在目标机器上用基准测试判断。