6.2 SIMD 与性能扩展

6.2 SIMD 与性能扩展

本节摘要：SIMD 提案给 Wasm 带来 128 位向量类型 v128：一条指令并行处理四路整数或两路双精度浮点，编解码、媒体处理与密码学因此获得成倍吞吐。本节拆解向量类型与车道（lane）语义、走通自动向量化与手写内在函数两条路线，并归拢批量内存等其余性能家族。

SIMD（Single Instruction, Multiple Data，单指令多数据）是本节全部内容的心智起点：CPU 的一类宽寄存器，把多个数据元素并排装进去，一条指令同时对所有元素做同样的运算。把它想成"一条指令拉一排集装箱"即可——批量整齐的货物收益最大，零散不齐的货物反而要为装箱付成本。

v128 与车道语义

向量提案只引入一个新类型 v128——恒为一百二十八位，不区分内容；"里面装什么"由指令决定。同一块 v128 可以被当作四路 i32、八路 i16、十六路 i8 或两路 f64 来运算，每个格子叫一个车道（lane）。车道语义是全部向量指令的钥匙：

(module
  (memory 1)
  ;; 把内存里连续四个 i32 与另外四个相加
  (func $add4 (param $a i32) (param $b i32)
    ;; 从内存各加载一个四车道向量
    (local $va v128) (local $vb v128)
    (local.set $va (v128.load (local.get $a)))
    (local.set $vb (v128.load (local.get $b)))
    ;; 一条指令完成四个加法
    (i32x4.add (local.get $va) (local.get $vb))
    (v128.store (local.get $a))))
​

常用指令按功能分四族：算术族（i32x4.add、f32x4.mul 等，逐车道运算）；装载存储族（v128.load、v128.store 及对齐变体）；车道操作族（i32x4.splat 把标量铺满四车道、i32x4.extract_lane 取单车道、i8x16.shuffle 重排十六个字节）；比较掩码族（f32x4.eq 等逐车道比较产出全零全一的掩码，与位选择指令配合实现无分支逻辑）。最后一族值得专门练习——分支消除是向量代码与标量代码手感差异最大的地方，"逐车道判断加掩码选择"替代了 if 语句。

两条使用路线：让编译器干与亲手干

自动向量化路线是默认推荐：LLVM 后端在开启 SIMD 目标后会把规整的标量循环自动改写为向量指令。对 Rust 工程只需换目标并注意代码形态：

$ export RUSTFLAGS="-C target-feature=+simd128"
$ cargo build --target wasm32-unknown-unknown --release
​

// 规整的循环最容易被自动向量化：步长固定、无分支、内存连续
pub fn sum_u8(data: &[u8]) -> u32 {
    data.iter().map(|&b| b as u32).sum()
}
​

自动向量化的收益取决于代码形态：步长固定、无数据依赖、内存对齐的循环近乎白拿收益；带复杂分支或跨迭代依赖的循环则纹丝不动。把热点循环改造成"向量化友好"形态，比手写向量代码的性价比高得多。

手写内在函数路线用于自动向量化够不着的场合——混排、掩码选择、精度换速度的算法。Rust 侧用核心架构 intrinsic 或 portable SIMD 抽象书写，编译器映射到对应 v128 指令。手写的代价是可读性与可移植性双降，纪律是：先证明热点确实在循环（剖析说话），再手写；写完立刻建立标量版基准，回归测试永远保留标量实现兜底。

理论加速比按车道数封顶——四路整数即四倍，实际收益取决于内存带宽与车道利用率，媒体处理的典型区间在两到三倍之间。判定值不值的上限标准也很直白：数据不整齐、算法有分支密集判断的场景，向量化的收益经常为零甚至为负。

把"改造成向量化友好"具体演示一遍。假设有个按阈值统计像素的循环，原写法带分支：

// 分支版：每个元素一次条件跳转，向量化器只能干瞪眼
pub fn count_bright(px: &[u8], threshold: u8) -> u32 {
    let mut n = 0;
    for &v in px {
        if v > threshold { n += 1; }
    }
    n
}

// 无分支版：比较产生零一掩码再求和，四车道并进
pub fn count_bright_fast(px: &[u8], threshold: u8) -> u32 {
    px.iter().map(|&v| ((v > threshold) as u32)).sum()
}
​

改动只有一处语义等价的形态变换——条件累加改为零一累加——编译器随即能把循环改写为向量比较加水平求和。这就是"为向量化改形态"的全部诀窍：消除分支、消除跨迭代依赖、让每轮迭代做一样的事。基准验证的顺序照旧：改形态、跑基准、确认收益、再决定去留。

性能扩展家族：SIMD 之外的增补

向量提案之外，性能家族还有几个成员值得点名。批量内存操作（memory.copy 与 memory.fill）在第三章已经用过——整块搬移取代手写循环，对大缓冲的初始化与拷贝有立竿见影的收益。宽松 SIMD（relaxed SIMD）给少数向量指令开了"允许实现差异"的口子：引擎可以选平台上更快的原生变体，代价是跨引擎结果可能有一位之差——用在不比精度比吞吐的媒体管线里正合适。尾调用（tail call）让函数尾部的调用不增长栈，解释器与状态机类代码的深层递归从此安全。多值返回与签名扩展则早在引用类型提案中并轨，编译器产物的形态因此更紧凑。

本节要点回顾

• v128 恒宽一百二十八位：装什么由指令决定，车道语义是理解全部向量指令的钥匙；
• 掩码选择替代分支：逐车道比较加位选择是向量代码的基本功，也是收益来源；
• 自动向量化优先：规整循环近乎白拿收益，手写内在函数留给剖析证明过的热点；
• 收益上限看车道利用率：数据整齐无分支的两到三倍常见，零散分支密集的场景可能白忙；
• 性能家族按状态采用：向量与批量内存可上生产，宽松 SIMD 看精度容忍度，其余保持观察。

吞吐的短板补完，下一节补表达力的短板：垃圾回收提案如何为托管语言打开这扇门。