Go simd 怎样让同一算法在不同架构回退执行

如果同一段 Go 数值算法要同时跑在 amd64、arm64 和 WebAssembly 上，直接写固定宽度的 SIMD 指令很容易把实现绑死在某一种 CPU 上。Go 1.27 的实验性 simd 包把向量长度从业务代码里隐藏起来：支持硬件 SIMD 时使用对应实现，当前平台没有可用指令时则使用纯 Go 模拟。因此，跨架构回退的关键不是为每个 CPU 复制一份算法，而是把公共算法写在可移植 API 上。

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

优先使用 simd 的交集 API，并把完整块、尾部数据和结果比较写清楚；只有公共 API 确实缺少某个操作时，才下沉到 simd/archsimd，同时保留共享的 emulation 分支。

• 公共算法：使用 simd.Float32s、Load...Part 和向量方法，不写死 128/256/512 位。
• 硬件选择：由 Go 的实验性 SIMD 实现根据平台和可用特性选择硬件向量或模拟路径。
• 特殊能力：用架构文件处理特有指令，用同一份 emulation 兜底，保持输出语义一致。

先把算法放进可移植 simd 层

simd 的向量类型使用复数形式命名，例如 Float32s。它不把固定的元素数量暴露给算法，代码只需要通过零值向量的 Len() 取得本次运行的向量宽度。这样，同一个循环在支持 128 位、256 位或 512 位向量的机器上都能复用。

下面的示例把两个浮点切片逐元素相加。它刻意把“整块加载”和“尾部加载”分开，避免最后一段不足一个向量时越界。示例依赖实验性包，文件顶部的构建约束和构建命令要配套使用。

//go:build goexperiment.simd

package main

import "simd"

// addPortable 让同一份加法算法覆盖硬件向量和纯 Go 模拟路径。
func addPortable(dst, a, b []float32) {
	// 先保证输入长度一致，避免尾部处理把错误带到向量层。
	if len(a) != len(b) || len(dst) 

这段代码没有判断“当前是 Intel、Apple Silicon 还是 wasm”，因为那不是公共算法应该承担的职责。LoadFloat32sPart 和 StorePart 负责把尾部边界变成 API 语义，调用方只需保证两个输入的有效区间一致。

回退发生在哪里：硬件向量或纯 Go 模拟

使用 GOEXPERIMENT=simd 构建后，simd 会根据平台选择可用的硬件实现；如果平台没有支持的 SIMD 指令，或当前实现不覆盖该平台，操作会落到模拟实现。Go 官方文档还提供了 simd.Emulated() 和 simd.VectorBitSize()，可用于记录本次运行处于哪种模式，而不是把 CPU 名称写死在业务分支中。

//go:build goexperiment.simd

package main

import (
	"fmt"
	"simd"
)

func printSIMDMode() {
	// 这两个值只用于诊断，不改变公共算法的结果。
	if simd.Emulated() {
		fmt.Println("simd mode: emulation")
		return
	}
	fmt.Printf("simd mode: hardware, vector bits=%d\n", simd.VectorBitSize())
}

构建和回退检查可以分成两次：第一次使用默认硬件路径，第二次强制模拟。这里比较的是输出是否一致，不是把一次本地运行的耗时当成跨架构性能结论。

# 用实验性 SIMD 功能构建并运行测试。
GOEXPERIMENT=simd go test ./...

# 强制使用模拟路径，检查同一算法的结果语义。
GOEXPERIMENT=simd GODEBUG=simd=0 go test ./...

公共 API 缺少操作时，再隔离 archsimd

可移植 API 只收录不同架构的共同交集，所以并不是每一条硬件指令都会直接出现。如果算法确实需要某个尚未提供的操作，可以让公共函数继续接收 simd 类型，再用 ToArch() 进入架构专用类型；每个架构分支最后都要回到 simd.FromArch，而默认分支调用共享的 emulation。

//go:build goexperiment.simd && amd64

package main

import (
	"simd"
	"simd/archsimd"
)

// specialOp 在 amd64 上使用专用操作，其余情况仍回到公共模拟函数。
func specialOp(v simd.Int8s) simd.Int8s {
	switch x := v.ToArch().(type) {
	case archsimd.Int8x16:
		// 只有当前类型确实支持该操作时才使用架构专用实现。
		return simd.Int8sFromArch(x.OnesCount())
	default:
		// GODEBUG=simd=0 或未覆盖的向量形状都走同一份 emulation。
		return specialOpEmulated(v)
	}
}

这类代码必须按架构拆分并配合 build tag；不要在一个文件里假设所有机器都有同样的 archsimd 类型。更重要的是，模拟函数和硬件函数要定义同一个输入输出语义，尤其要明确掩码、尾部元素、溢出和浮点舍入等边界。

用结果一致性决定是否采用

跨架构 SIMD 的第一道检查不是“哪台机器更快”，而是硬件路径、固定向量长度路径和纯 Go 模拟路径对同一组输入给出相同结果。测试数据要覆盖空切片、长度小于向量宽度、恰好整块、带尾部以及会触发掩码的输入。

如果算法只使用加减乘、比较、加载、存储和 IfElse 等公共操作，优先停留在 simd 层；如果必须调用 archsimd，就把专用代码限制在薄薄的一层，并让默认分支永远可用。这样新增架构时只需补一个适配实现，业务算法和结果判断不必重写。

常见问题

没有 SIMD 指令的机器会直接崩溃吗？

使用可移植 simd API 时，官方设计包含纯 Go 模拟路径，代码仍可运行。真正需要谨慎的是直接使用 archsimd 的特定指令：这时必须做能力判断并保留回退，不能把某个 CPU 特性当成所有部署环境的前提。

为什么不直接把向量宽度写成 4 或 8？

固定元素数量会把算法和某种寄存器宽度绑定，也会让尾部处理与跨架构测试变复杂。使用 Len()、Load...Part 和 StorePart，才能让同一份代码适应不同向量长度。

最终可以把决策记成一句话：公共计算放在 simd，特有指令放在隔离的 archsimd 适配层，任何路径都共享可比较的 emulation 结果。先保证语义一致，再用针对目标架构的基准测试决定硬件优化是否值得。