Go simd/archsimd 怎样选择 amd64 与 arm64 向量实现

Go 里的 simd 和 simd/archsimd 不是同一层 API。选择时可以先记住一句话：能用跨平台向量抽象解决的问题，优先放在 simd；只有算法确实依赖某个架构特有的指令或数据形状时，才把很小的一段实现下沉到 simd/archsimd。

官方资料：https://go.dev/blog/archsimd

官方包文档：https://pkg.go.dev/simd/archsimd

截至 Go 1.27，这两套 API 都需要在构建时启用 GOEXPERIMENT=simd。官方实验覆盖 amd64 的 AVX、AVX2 和部分 AVX-512，arm64 的 NEON，以及 wasm 的 128 位 SIMD；本文只讨论 amd64 与 arm64 的代码组织和回退边界。

先区分 simd 与 simd/archsimd 的职责

simd 面向“同一段算法在多个平台复用”的场景，目标是让调用方不必直接写死向量宽度。simd/archsimd 则更接近底层 intrinsics：它暴露架构相关的向量类型、操作和 CPU 特性检查，代价是类型和可用操作会随着目标架构变化。

因此，选择可以按下面的顺序判断：

• 如果核心需求是批量加法、比较、掩码或规约，而且 amd64 和 arm64 都应该有同一套算法，先看 simd 是否已经提供对应操作。
• 如果需要某个平台独有的指令，例如只在特定 CPU 扩展上有意义的操作，再在架构文件中使用 archsimd。
• 如果只是想让普通循环更快，先保留标量实现；实验 API 的开启、CPU 特性和部署平台都应该是可控条件，而不是公共接口的隐含前提。

还有一个重要边界：不要把 archsimd.Float32x4、archsimd.Float32x8 之类的类型放进公共业务 API。官方文档明确提示，架构相关类型不具备可移植性；公共层可以传切片、普通结构体或业务接口，把向量类型留在实现文件内部。

amd64 与 arm64 的选择点不一样

amd64 的可选向量能力比较多，代码通常需要先判断 AVX、AVX2 或 AVX-512 等扩展是否存在。编译目标是 amd64，并不等于运行这段程序的每一台机器都支持你想用的最高级指令集。把“目标架构”与“当前 CPU 特性”混为一谈，是最常见的崩溃或非法指令风险来源。

arm64 的基础 SIMD 能力是 NEON，官方 archsimd API 还为可选扩展提供了特性查询，例如 archsimd.ARM64.PMULL()。普通浮点向量加法可以按 NEON 基线组织；只有使用可选扩展的算法，才需要再增加对应的运行时分支。

用构建标签隔离架构实现

构建标签解决的是“哪些源文件参与编译”，运行时特性检查解决的是“当前 CPU 能不能走优化路径”。两者必须分开。一个简单的目录可以让公共层只依赖一个普通函数：

vector/
  add.go          # 公共入口，不暴露向量类型
  add_scalar.go   # 没有实验 API 或不支持架构时的回退
  add_amd64.go    # amd64 + simd 实现
  add_arm64.go    # arm64 + simd 实现

公共入口只处理切片和边界，具体文件再决定如何加载向量。下面的文件头使用了 Go 实验包实际采用的 goexperiment.simd 构建标签；如果项目不希望依赖这项实验能力，也可以把优化实现放在独立模块中。

//go:build goexperiment.simd && amd64

package vector

import "simd/archsimd"

func addFloat32(dst, a, b []float32) {
    // amd64 先检查 AVX2，避免把可选指令当成所有机器的默认能力。
    if !archsimd.X86.AVX2() {
        addScalar(dst, a, b)
        return
    }

    // Float32x8 一次处理 8 个元素，尾部不足一个向量时交给标量循环。
    width := 8
    i := 0
    for ; i+width 

这段示例的重点不是把一个固定向量宽度当成通用答案，而是展示隔离方式：amd64 文件只在目标架构和实验标签同时满足时参与编译，运行时再判断 AVX2。实际项目还应根据所用的 simd/archsimd 版本确认具体向量类型和操作名。

arm64 以 NEON 为基础，扩展能力单独判断

arm64 文件可以沿用同一个公共函数名，但不应该复制 amd64 的向量宽度假设。当前 API 的固定宽度 NEON 例子可以用 Float32x4 表示 4 个 float32；如果算法依赖 PMULL 等可选扩展，则把检查写在真正需要它的分支上。

//go:build goexperiment.simd && arm64

package vector

import "simd/archsimd"

func addFloat32(dst, a, b []float32) {
    // arm64 的普通浮点向量路径以 NEON 为基础，不把 PMULL 当成前置条件。
    width := 4
    i := 0
    for ; i+width 

这里的 archsimd.ARM64.PMULL() 只是特性查询示例，不代表普通加法需要 PMULL。把扩展检查缩小到真实依赖它的算法，有助于让回退路径更容易阅读和测试。

没有实验 API 或 CPU 能力不足时保留标量回退

回退文件应该拥有与优化文件相同的公共内部函数签名。这样上层业务只调用 Add，不会感知当前是向量实现还是普通循环；也不会因为一台较旧的 amd64 机器没有 AVX2，就在启动后才发现不可执行。

//go:build !goexperiment.simd || (!amd64 && !arm64)

package vector

func addFloat32(dst, a, b []float32) {
    // 回退路径不依赖实验包，保证普通构建和其他架构仍可用。
    addScalar(dst, a, b)
}

func addScalar(dst, a, b []float32) {
    // 以最短切片为边界，避免示例函数因输入长度不同而越界。
    n := len(dst)
    if len(a) 

如果项目要求所有平台都能构建，回退实现不是可有可无的测试替身，而是发布契约的一部分。它还可以作为正确性基线：先让标量结果稳定，再比较各架构向量实现的结果和边界行为。

把构建检查和交叉测试放进发布清单

由于 simd/archsimd 是实验 API，发布前至少要把“是否启用实验开关”和“目标架构是否支持该包”写进构建脚本。交叉编译只能证明代码能面向某个目标架构构建，不能代替在真实 CPU 上检查可选指令；两者应分别安排。

# 开启实验 SIMD，先检查当前工具链能否测试架构包。
GOEXPERIMENT=simd go test simd/archsimd/...

# 交叉检查 arm64 目标的公共包和回退边界。
GOOS=linux GOARCH=arm64 GOEXPERIMENT=simd go test ./...

# 在 Apple Silicon 上检查 amd64 目标的编译边界；运行时能力仍需真实 amd64 环境确认。
GOARCH=amd64 GOEXPERIMENT=simd go test ./...

真正的回归清单可以压缩成四项：

1. 公共 API：业务包不出现 archsimd 向量类型，架构差异停留在实现层。
2. 构建矩阵：至少覆盖 GOARCH=amd64、GOARCH=arm64 和未启用实验 API 的普通构建。
3. 特性矩阵：amd64 分别覆盖满足和不满足 AVX2 的路径；arm64 对可选扩展覆盖 true/false 分支。
4. 结果矩阵：向量块、尾部元素、空切片、不同输入长度和标量回退得到相同的业务结果。

什么时候该选哪一层

最终可以把决策落成一句工程规则：公共层只约定数据和结果，构建标签决定哪份实现进入二进制，运行时特性检查决定能否使用更高阶指令，标量实现永远负责兜底。这样 amd64 与 arm64 的差异是局部的，SIMD 优化也不会变成部署环境的硬编码假设。

常见问题

为什么 amd64 文件还要检查 AVX2？

GOARCH=amd64 只说明目标指令集架构，不说明当前运行 CPU 支持所有可选扩展。需要 AVX2 的路径应在运行时查询能力，不满足时退回标量或较低要求的实现。

arm64 都有 NEON 吗？

本文讨论的 Go arm64 SIMD 基础路径按 NEON 组织；但 PMULL、SVE 等扩展不能因为是 arm64 就一概视为可用。依赖可选扩展的代码仍要单独判断，并保留回退方案。

为什么不直接在公共函数里返回 archsimd 向量？

因为 amd64 与 arm64 的向量类型、宽度和可用操作不同，公共 API 会因此被架构绑定。让公共层使用切片或普通业务类型，可以把平台差异限制在构建约束文件中。

只做交叉编译就能证明 SIMD 正常吗？

不能。交叉编译主要验证目标架构的源文件选择和类型检查；运行时可选指令是否可用，还需要在对应 CPU 能力矩阵中执行测试。

总结：跨平台算法优先看 simd，架构专属能力再用 archsimd；amd64 把 AVX 等扩展当作运行时条件，arm64 以 NEON 基础路径处理并单独判断可选扩展；所有架构文件都应通过构建标签隔离，公共层保留标量回退。用这条边界组织代码，才能在性能、可移植性和发布风险之间取得稳定平衡。