Go SIMD 向量宽度怎么影响切片分块

我以前写 SIMD 循环时，最容易把“256 位向量一次处理 8 个 float32”直接写进步长。这样在当前机器上能跑，换到 128 位、512 位或纯 Go 模拟实现时，切片边界就不再可靠。

直接答案：Go 的实验性 simd API 故意隐藏固定向量宽度。切片分块不要写死为 4、8 或 16，而要从具体向量类型的 Len() 取得本次运行可容纳的元素数。完整块使用 Load…/Store，最后不足一个向量的尾块使用 Load…Part/StorePart。

Go 官方 SIMD 文章：https://go.dev/blog/simd-experiment

以下内容以 Go 1.27 的实验接口为准，构建时需要启用 GOEXPERIMENT=simd。实验 API 仍可能调整，不应把当前细节当成永久稳定承诺。

接口目标：分块逻辑不绑定某一种向量宽度

Go 官方的设计目标是让同一份 SIMD 代码在不同平台和向量宽度上运行。simd.Float32s、simd.Uint8s 这类类型不在名称里携带 128、256 或 512 位；平台支持不足时还可以使用模拟实现。

这意味着调用方只应关心“当前向量能装多少个这种元素”。对同一个 256 位向量，float32 每个元素占 32 位，可装 8 个；uint8 每个元素占 8 位，可装 32 个。向量位宽相同，元素类型不同，切片步长仍然不同。

调用方需求：块大小来自 Len，而不是硬编码

向量类型的零值有效，因此可以声明一个零值向量，只用它查询 Len()。官方文档还说明，同一次程序执行中所有 SIMD 向量拥有相同位宽，但不同元素类型的 Len() 会按元素大小换算。

循环边界推荐写成 i+width 。它直接表达“剩余元素至少够一个完整向量”，比 i 更容易审查，也便于在进入循环前处理长度检查。

参数设计：完整块和尾块使用两套 API

LoadFloat32s 适合长度至少为一个完整向量的切片区间；LoadFloat32sPart 用于不足一个向量的尾部，它会加载现有元素、用零填充其余槽位，并返回实际加载数量。对应地，StorePart 只把目标切片能容纳的有效部分写回。

这个接口拆分非常重要：主循环没有掩码和分支负担，尾块也不需要手写标量循环。只要向量运算对零填充是安全的，就能复用同一组计算表达式。

错误模型：先约束切片，再进入向量循环

SIMD API 负责向量装载和计算，不替调用方判断三个业务切片是否具有相同长度。最稳妥的做法是让函数先检查输入与输出长度，再执行分块。空切片天然通过：完整块循环不进入，尾块分支也不进入。

如果算法对零填充不封闭，例如除法的分母不能为零、索引值会参与后续查表，尾部就不能机械使用 Part API。此时应为尾块构造安全填充值、配合有效元素数或退回标量处理。分块策略必须服从运算语义，而不是为了“全程 SIMD”牺牲正确性。

兼容策略：不要假设测试机就是部署机

Go 1.27 还允许用 GODEBUG=simd=0 测试模拟实现，或用相应设置选择 128、256、512 位级别。它适合暴露硬编码宽度和尾部处理问题，但这些设置属于测试与诊断手段，不应替代代码中的动态 Len()。

示例：按当前向量长度完成 float32 切片相加

package vectoradd

import (
    "fmt"
    "simd"
)

// AddFloat32 把 a、b 逐元素相加并写入 dst。
func AddFloat32(dst, a, b []float32) error {
    if len(dst) != len(a) || len(a) != len(b) {
        // 业务层先统一长度，避免三个切片分块边界不一致。
        return fmt.Errorf("slice length mismatch: dst=%d a=%d b=%d", len(dst), len(a), len(b))
    }

    var probe simd.Float32s
    width := probe.Len() // 当前运行时一个向量可容纳的 float32 数量。
    i := 0

    for ; i+width 

这里用零值 simd.Float32s 查询宽度，不把机器能力写进函数签名。完整块和尾块使用不同装载接口，但核心运算都是 x.Add(y)，调用方体验保持一致。

测试时重点覆盖这些长度

• 0：确认空输入正常返回。
• 1 与 Len()-1：确认全部数据都走尾块。
• Len()：确认刚好一个完整块且没有尾块。
• Len()+1：确认完整块与单元素尾块正确衔接。
• 2×Len() 与 2×Len()+3：确认多个完整块及剩余元素。
• 长度不一致：确认函数在装载前返回业务错误。

这些用例应在模拟模式和可用的不同硬件宽度下重复。不要断言某台机器上的 Len() 必然等于固定值，而应根据测试运行时读取的宽度构造数据。

常见问题

能不能直接用 CPU 的 256 位宽度除以 32？

不建议。平台、可用特性和运行配置都会影响实际向量宽度，调用方应直接使用向量类型的 Len()。

尾部一定要退回普通 for 循环吗？

不一定。运算允许零填充时，可使用 Load…Part 和 StorePart；若零填充会改变语义，再采用掩码、安全填充值或标量尾循环。

为什么不把宽度作为函数参数？

平台无关接口的目标就是让调用方不管理硬件宽度。把固定宽度暴露成业务参数，会重新引入跨平台分支和错误组合。

现在适合用于稳定公共库吗？

simd 在 Go 1.27 中仍是实验 API，需要 GOEXPERIMENT=simd。可以评估和压测，但公共库应隔离实验实现，并保留普通 Go 回退路径。

归纳：向量宽度影响的是每次循环处理的元素数，而不是业务切片本身。把 Len() 作为唯一块宽来源，用完整接口处理主区间、用 Part 接口处理尾区间，就能让同一份 Go SIMD 代码跨 128、256、512 位和模拟实现保持正确。