SIMD 加速后结果出现微小误差该如何判断

我最近把一段浮点数组计算从标量循环改成 SIMD。基准测试很漂亮，但原来用 want == got 的测试开始失败：小数点后十几位只有最后一两位不同。第一反应很容易走向两个极端——要么认定 SIMD 算错了，要么随手放宽一个 epsilon 让测试变绿。后来复盘发现，这两种做法都不可靠。

先说结论：微小不等于可以忽略

SIMD 后出现末位差异，常见原因是加法归约顺序改变，或硬件把乘加合并成一次舍入的 FMA，而标量路径执行了乘法、加法两次舍入。这符合 IEEE 754 浮点运算的特性，并不自动等于实现错误。

但“正常产生”也不等于“业务可以接受”。正确的判断顺序是：先确定业务语义和容差预算，再用标量参考实现做差分，最后同时观察绝对误差、相对误差、ULP 距离和业务不变量。只要结果会进入金额、协议摘要、精确阈值分支或可重复构建，就不能拿“误差很小”作为放行理由。

影响面：性能通过了，精确相等测试却失败

这次问题出现在一段内积计算。标量版本按输入顺序逐项执行 sum += a[i] * b[i]；SIMD 版本先让每个向量 lane 分别累加，再把各 lane 写回并做一次标量归约。两段代码表达的是同一个数学公式，却没有承诺完全相同的舍入路径。

Go 官方在 portable SIMD 的内积示例中也采用了类似结构：向量部分使用 MulAdd，最后把各 lane 存入数组后标量求和。Go 1.27 的 portable SIMD 仍是实验功能，需要通过 GOEXPERIMENT=simd 开启；API 和编译器降级策略仍可能变化，因此更应该保留参考实现和差分测试。

触发条件：先做三路差分

我先固定一组能稳定复现的输入，然后分别运行标量参考、硬件 SIMD 和 SIMD 软件模拟。Go 的实验实现可用 GODEBUG=simd=0 强制走模拟路径，这对区分“算法分组差异”和“特定硬件 lowering 差异”很有用。

# 运行项目保留的标量参考测试，得到基准结果
go test ./...

# 开启 Go 实验性 SIMD，运行硬件可用路径
GOEXPERIMENT=simd go test ./...

# 关闭 SIMD 硬件加速，比较软件模拟路径
GODEBUG=simd=0 GOEXPERIMENT=simd go test ./...

比较时不要只记录“测试失败”。至少输出首个失败下标、参考值、实际值、最大绝对误差、最大相对误差和最大 ULP 距离。若模拟路径与硬件路径都以相似幅度偏离标量基线，优先检查归约顺序；若只有一种硬件路径异常，则继续缩小到数据类型、指令实现和特殊值。

根因一：归约顺序改变

浮点加法不满足严格的结合律。数学上 (a+b)+c 与 a+(b+c) 相等，浮点实现却可能在每次舍入后得到不同末位。标量循环通常是从左到右累加；SIMD 则把输入拆到多个 lane 中形成若干部分和，再合并部分和。输入值跨度越大、正负抵消越明显、累计项越多，顺序变化越容易被放大。

因此，第一个诊断动作不是增大 epsilon，而是确认两条路径是否使用了相同的数据类型和归约树。如果业务确实要求跨架构位级一致，应固定运算顺序、避免允许重排的优化，并接受由此带来的性能代价；如果业务只要求数值上足够接近，则把误差预算写进测试。

根因二：MulAdd 与 FMA 的舍入次数不同

math.FMA(x, y, z) 的定义是计算 x*y+z，但只做一次舍入。普通的 x*y+z 可能先对乘法结果舍入，再对加法结果舍入。两者通常非常接近，却不保证最后几位完全一致。

同样的差异也可能出现在 SIMD 的 MulAdd。硬件有原生融合乘加时可能使用一次舍入，而某些软件模拟或目标架构可能表现为先乘后加。排障时应把“公式相同”和“舍入路径相同”分开记录，不能用前者推导后者。

修复动作：把误差判定写成可审计代码

对一般数值结果，我会同时给出绝对容差和相对容差。绝对容差照顾接近零的值，相对容差照顾量级较大的值；两个参数都由业务或算法误差预算传入，不在工具函数里藏一个万能常数。

package numeric

import "math"

// AlmostEqual 使用绝对误差和相对误差联合判断。
// absTol 与 relTol 必须来自当前业务的误差预算。
func AlmostEqual(want, got, absTol, relTol float64) bool {
	// NaN 与任何值都不应被视为近似相等。
	if math.IsNaN(want) || math.IsNaN(got) {
		return false
	}
	// 这一步同时处理完全相等、同号无穷和正负零。
	if want == got {
		return true
	}

	diff := math.Abs(got - want)
	if diff 

调用侧还应拒绝负容差，并在断言失败时打印两种误差。这样以后调整容差时，有证据说明是输入范围或业务要求改变，而不是为了让某个平台过测试。

选择容差：绝对误差、相对误差和 ULP 各管什么

绝对误差是 |got-want|，适合零附近或量纲明确的上限；相对误差用误差除以参考量级，适合跨多个数量级的数据；ULP 距离衡量两个浮点数之间隔了多少个可表示值，更适合定位实现差异和比较相同精度的结果。

ULP 很适合诊断，却不是跨量级的万能业务标准。下面的函数把 float64 映射到单调整数空间，再计算距离；NaN 和无穷需要显式排除。标准库的 math.Nextafter 则可以帮助理解“向目标方向的下一个可表示值”。

package numeric

import "math"

// orderedBits 把 float64 映射到按数值单调排列的整数空间。
func orderedBits(x float64) uint64 {
	b := math.Float64bits(x)
	if b&(uint64(1) ob {
		return oa - ob, true
	}
	return ob - oa, true
}

特殊值与阈值分支必须单独处理

只比较误差大小会漏掉最危险的边界。NaN 应明确判失败还是按领域规则传播；正负无穷只能与相同无穷精确相等；正零和负零在数值比较中相等，但如果后续观察符号位或执行倒数，它们的语义可能不同。

还要检查结果是否跨过业务阈值。比如 SIMD 结果只偏了一个 ULP，却让 score >= limit 从 false 变成 true，这个差异在数值上极小，在业务上却是离散变化。金额、限流、风控等级、物理稳定条件等分支，都应围绕阈值两侧建立专门测试。

防复发：把数值预算纳入测试与发布

最后我把这次故障收敛成六条固定规则：

• 保留简单、可读的标量参考实现，不与优化代码共用同一套归约逻辑。
• 保存能触发最大偏差的输入，覆盖大数加小数、正负抵消、次正规数、零、NaN 和无穷。
• 同时比较硬件 SIMD 与 GODEBUG=simd=0 模拟路径，并记录 Go 版本、架构和向量宽度。
• 测试报告输出最大绝对误差、相对误差、ULP 距离及失败下标，不只输出布尔值。
• 验证领域不变量，例如概率和、能量范围、单调性、非负性或守恒关系。
• 把正确性测试和性能基准分开；只有误差预算通过后，吞吐提升才有意义。

因此，“SIMD 加速后结果出现微小误差该如何判断”的最短答案是：先证明差异来自可解释的运算顺序或舍入路径，再证明它没有突破业务容差、不变量和阈值边界。能同时回答这两点，才可以把差异认定为可接受；否则就仍然是待定位的正确性问题。

官方资料

• Go portable SIMD 介绍：https://go.dev/blog/simd-experiment
• Go 架构专用 SIMD：https://go.dev/blog/archsimd
• Go 1.27 发布说明：https://go.dev/doc/go1.27
• math.FMA 文档：https://pkg.go.dev/math#FMA
• math.Nextafter 文档：https://pkg.go.dev/math#Nextafter