_mm_stream_si128优化实战：绕过内存带宽瓶颈的SIMD非临时写

1. 一次优化实测：从图像处理里挖出的性能黑洞

1.1 一段看起来正常的 SIMD 代码

先说个我自己的经历。前几年我在调一段图像滤镜代码，逻辑不复杂：读入一张大图的像素，做一个查表变换，再写回输出缓冲。最初版本是用标量循环写的，后来为了提速改成 SSE 向量化，核心代码差不多长这样：

c复制#include <immintrin.h>

void transform_rgba(unsigned char *dst,
                    const unsigned char *src,
                    int width, int height) {
    size_t total = (size_t)width * height * 4;
    size_t i = 0;
    for (; i + 16 <= total; i += 16) {
        __m128i pixel = _mm_loadu_si128((const __m128i *)(src + i));
        __m128i r = _mm_and_si128(pixel, _mm_set1_epi32(0xFF));
        // 这里做一连串查表和运算，省略细节
        __m128i result = ...; // 输出仍是 RGBA
        _mm_storeu_si128((__m128i *)(dst + i), result);
    }
    for (; i < total; i++) dst[i] = lut[src[i]];
}

编译开满优化后，我以为性能已经不错了。可实际一测 4K 分辨率的 RGBA 图，单帧耗时反而比手写标量版本好不了多少，跟理论上 SIMD 的 4 路并行完全不成正比。CPU 单核占用是满的，但内存控制器的带宽并没有跑满，这就很让人困惑。

后来我用性能分析工具跑了一圈，发现程序大部分时间停顿在访存阶段，算术指令的吞吐量远没有到极限。换句话说，这段代码不是“算不过来”，而是“等内存”。这正是 Memory-Bound 类算法的典型特征：计算单元在大部分时间里处于等待状态，瓶颈不在 CPU 主频，而在内存系统的读写流量。

1.2 为什么 CPU 占用很高但耗时很长

很多人一看到 CPU 占用率高，就以为瓶颈在计算。其实在内存受限场景下，CPU 占用率反而可能是 100%，因为它要反复发起访存指令并等待数据返回，只是这些“等待”消耗的不是执行单元，而是流水线停顿。你观察到的结果就是：占用率高、功耗高、性能上不去。

这类问题的几个信号很明确：

• 数据规模远大于 L2/L3 缓存，工作集动辄几十 MB 甚至上 GB；
• 算法对每个元素的“计算量”很低，比如拷贝、变换、清零、阈值化；
• 一个循环体内累加消耗的时间，和内存带宽强相关；
• 用 perf stat -d 查看时，stalled-cycles-backend 占比很高。

我当时拿到的指标里，后端停顿时钟周期占了 60% 以上，内存带宽理论值约 20GB/s，可程序实际带宽只有一半。说明这块代码的确还有优化空间。今天要讲的 _mm_stream_si128，就是解决这类问题的一个非常锋利，但也非常容易用错的工具。

2. Memory-Bound 的底层逻辑：计算在等内存，还是内存在等计算

2.1 一个简单的带宽模型

要理解 _mm_stream_si128 为什么有效，先要建立一个带宽思维模型。

假设你要处理 1GB 的数据，CPU 每秒能执行 10 亿次简单运算，内存带宽是 20GB/s。如果每个元素只做一次加法，那么单核 CPU 处理 1GB 大约需要 1 秒（10 亿次），而光把 1GB 数据从内存搬到 CPU 就需要 0.05 秒。看起来 CPU 更慢？实际上现代 CPU 的单个核心并不一定能每秒执行 10 亿次访存循环，因为每次内存访问都有延迟，而普通 SIMD 循环里如果只算一次加法，访存等待会吃掉指令流水的绝大部分时间。

更准确的计算方式应该是这样：

• 整个过程的总数据流量 = 读流量 + 写流量；
• 理论最短时间 = 总数据流量 / 内存带宽；
• 真实时间还会受缓存命中率、DRAM 行激活、NUMA 距离影响。

如果按这个公式算出来，程序实际耗时接近理论值，那它就是 Memory-Bound 的典型形态。如果算出来的理论耗时远低于实际耗时，比如实际耗时是理论的两倍以上，说明中间有大量“多走的路”。其中最常见的，就是普通写操作引起的读改写开销。

2.2 普通 store 的隐藏开销：写分配与 RFO

写一个字节到内存，表面上只是把数据放过去。但在 x86 架构里，普通 store 指令一旦发生缓存未命中，处理器并不会直接把这个字节写进 DRAM，而是先发起一个 Read For Ownership 操作，把包含这个地址的一整条缓存行（通常 64 字节）从内存读到缓存里，然后在缓存行上修改。这个流程叫“写分配”。

关键是：如果这段数据以后根本不会被读，那么这趟“预读”就是纯粹的浪费。比如一个大数组清零，你用 _mm_store_si128 写 16 字节，第一次写时因为缓存未命中，系统会把 64 字节读进来，再修改其中 16 字节；后面 3 次写同一缓存行时虽然不再需要读，但最终整条脏缓存行还是会被写回内存。于是，一个简单的清零过程，实际内存流量变成了：先读 1GB，再写 1GB，总共 2GB。

而 _mm_stream_si128 使用的是非临时写指令，它走的是另一条路：绕过缓存，把数据合并进 write-combining 缓冲区，尽量凑满整个缓存行后直接写回内存。整个过程不需要先“读”一次，这 1GB 的读流量就被省掉了。

3. _mm_stream_si128 的底层机制：一条指令如何省掉一半流量

3.1 MOVNTDQ 与 write-combining 缓冲

_mm_stream_si128 在底层会被编译成 movntdq 指令，其中的 nt 就是 non-temporal，意思是“不需要缓存”。它的设计初衷是给那些对缓存没有复用价值的写操作使用。

它的内部路径和普通写有很大区别。普通写是：store →缓存 →标记 dirty → 写回内存。而 movntdq 是：store →写入写合并缓冲区 → 合并到完整缓存行 → 直接写 DRAM。CPU 内部的 write-combining buffer 数量有限，通常只有几个条目。如果你的循环能够快速连续填满一个缓存行的各个部分，那么这些写操作会被合并成一次整行写入，效率最高。

这也是为什么 _mm_stream_si128 最适合“逐块连续写”的场景。如果每写 16 字节就跳到很远的地址，写合并缓冲区不断被冲刷，性能会打折扣。

3.2 与普通 _mm_store_si128 的路径对比

我列个表，方便观察两者的本质差异：

从表中能看出，流式写节省的不只是“读流量”，还顺带解决了缓存污染问题。比如一个 1GB 图像的中间结果，写进去之后再也不读，那么用普通 SIMD 写不仅多消耗读带宽，还会把大量宝贵的缓存空间填满，把后续真正要复用的数据挤出去。_mm_stream_si128 直接把数据“送走”，缓存保持干净，后续读操作命中率自然更高。

3.3 _mm_sfence 不是可选项

这里必须强调：使用 _mm_stream_si128 之后，一般要搭配 _mm_sfence()。

movntdq 是弱顺序写，编译器不保证它和其他 store 的先后顺序。如果你写完流式数据后，马上写一段普通数据，并且后续依赖这两者的顺序，那最后可能“普通数据已经生效、流式数据还没落盘”。在多线程场景下，其他核可能观测到奇怪的顺序。_mm_sfence() 的作用就是把所有之前的 non-temporal store 刷出写合并缓冲区，并保证后续 store 不会超越它。

我见过不少人在流式写之后不写 _mm_sfence，结果单线程测试没出问题，一到多线程配对就出现偶发数据错误。真正定位时会非常痛苦。所以顺手加上这一行，成本极低，能省掉很多隐患。

4. 实操改造：两个可以“抄作业”的模板

4.1 模板一：大数组置零

最典型也最简单的场景，是把大数组清零。用普通循环写 a[i] = 0 时，如果数组足够大，RFO 的开销非常可观。改成流式写后，逻辑几乎不用变：

c复制#include <immintrin.h>
#include <stddef.h>
#include <stdint.h>

void zero_array_stream(int32_t *a, size_t n) {
    size_t i = 0;
    __m128i zero = _mm_setzero_si128();

    // 一次写 4 个 int32_t，共 16 字节
    for (; i + 4 <= n; i += 4) {
        _mm_stream_si128((__m128i *)(a + i), zero);
    }

    // 流式写需要显式保证可见顺序
    _mm_sfence();

    // 剩余不足 4 个的元素用标量收尾
    for (; i < n; i++) {
        a[i] = 0;
    }
}

注意，a 的起始地址必须 16 字节对齐。常见的 malloc 只保证 16 字节对齐（不同平台不一样，通常是 16），但如果你用数组结构体，最好用 alignas(16) 或 _mm_malloc 分配。如果地址不对齐，movntdq 会直接触发异常，而不是乖乖帮你降级为未对齐写。

4.2 模板二：只写不读的图像处理

图像类的算法非常契合流式写，因为输出缓冲区往往就是拿来计算完直接交给下一步的，中间不会回头读。比如灰度化、阀值二值化、格式转换，这类循环都可以把输出写改成 _mm_stream_si128。

c复制void threshold_grayscale(uint8_t *dst,
                         const uint8_t *src,
                         size_t pixel_count,
                         uint8_t threshold) {
    size_t i = 0;
    __m128i thresh = _mm_set1_epi8((char)threshold);
    __m128i mask = _mm_set1_epi8(0xFF);

    for (; i + 16 <= pixel_count; i += 16) {
        __m128i v = _mm_loadu_si128((const __m128i *)(src + i));
        // 大于阈值保留灰阶，否则置 0
        __m128i cmp = _mm_cmpeq_epi8(_mm_max_epu8(v, thresh), v);
        __m128i out = _mm_and_si128(v, _mm_and_si128(cmp, mask));
        // 对输出做流式写
        _mm_stream_si128((__m128i *)(dst + i), out);
    }
    _mm_sfence();

    for (; i < pixel_count; i++) {
        dst[i] = src[i] > threshold ? src[i] : 0;
    }
}

这里有几个细节值得注意：

1. 输入 src 用普通 load 是合理的，因为读数据是算法本身的必要动作。如果这个 src 后续不会再被使用，你也可以用 _mm_stream_load_si128，但它的收益通常没有流式写那么明显，而且语义更微妙，我不建议在不确定时乱用。
2. dst 和 src 指向同一块内存时，要小心。流式写绕过缓存，可能让后续读旧数据的操作看到不一致的值。别在同一个循环里写又读同一地址。
3. 输出地址最好是 16 字节对齐的，但图像行宽不一定是 16 的倍数。处理跨行时，建议保证每行起始指针按 16 对齐，或者单独处理行尾的剩余像素。

4.3 编译与对齐选择

编译器需要知道当前 CPU 支持 SSE2。绝大多数 x86-64 CPU 都支持，所以 64 位环境下无需额外选项。如果你在 32 位环境，记得加 -msse2。调试阶段可以用 -O2 -march=native。

对齐分配我推荐两种方式：

c复制// Windows / MSVC 风格
float *a = (float *)_aligned_malloc(n * sizeof(float), 16);
...
_aligned_free(a);

// C11 / POSIX 风格
float *a = NULL;
posix_memalign((void **)&a, 16, n * sizeof(float));
...
free(a);

我比较喜欢 _mm_malloc，因为它和 _mm_free 配对，语义清晰。不过现在 C++ 项目也可以直接用 alignas(16) std::vector 配合自定义分配器，注意 vector 内部内存的起始地址不一定对齐，需要包装一层。

5. 实测数据：三组场景下的优化前后对比

5.1 场景A：1GB 数组清零

我在一款桌面 CPU 上做过一个简单测试：用 _mm_store_si128 逐段清零 1GB int32_t 数组，再用 _mm_stream_si128 清同一份数据，各跑三次取最好成绩。结果如下：

这里有意思的是，按“有效带宽”算流式版本反而看起来低了，但实际 wall time 快了近一倍。原因就在于普通 store 多跑了一倍的流量。如果只看执行时间，你才能真正感受到那个 RFO 读操作有多贵。

需要注意的是，数值会受 DRAM 频率、内存插法、是否运行在双通道等影响。重点不是绝对值，而是这个对比趋势：在一份不会回读的大数组上，流式写节省的时间基本等于省下的读带宽。

5.2 场景B：大图“灰度化+降噪”写入

第二个测试是处理一张 8000×6000 的 8 位灰度图，输入是随机噪声图，输出是滤波后的另一块缓冲。算法本身是 3×3 邻域均值，计算量比清零大不少，但因为输出缓冲区是全新的，且之后只读一次，我顺手把输出改成了流式写。

优化前：普通 SIMD 写，整个过程约 43ms。
优化后：流式写，整个过程约 31ms。

这次提升没有清零那么夸张，因为每像素的计算量变大，内存带宽不是唯一瓶颈。但 28% 的收益依然很可观。注意：我没有对输入做流式读，因为输入每个像素会被邻域权重读到多次，普通缓存反而能提供帮助。

5.3 场景C：把流式写用在反复读取的小缓冲上

第三个测试是我故意做的一个“反例”：一个 1MB 的缓冲区，循环里先流式写 16 字节，然后再 _mm_load_si128 读同一个位置，循环一百万次。结果让人很意外，流式版本比普通 store 慢了近 30 倍。

原因也很明显：流式写绕过了缓存，后续的读操作没法从 L1 拿到刚写的数据，只能从 DRAM 重新载入。而普通 store 因为写分配，数据就留在 L1 里，读回来几乎零成本。

这个反例值得所有想要“无脑替换”的人记住：只有当写入的数据近期内不会被读回时，流式写才有价值。

6. 适用边界与决策思路：什么时候该用，什么时候千万别用

6.1 判据一：写后是否很快被读

这是第一准则。如果你写完一块数据后，几行代码之内就要读它，那别用 _mm_stream_si128。缓存一致性是你的朋友，而不是敌人。普通 store 会主动把写的数据放进缓存，让随后的读取享受高速命中；流式写等于亲手把这个优势丢掉。

举个例子：矩阵转置算法里，写出的数据经常会作为后续计算的输入，且转置后立即参与下一轮运算。这种场景就不适合对输出做流式写，因为下一次读取没有足够的时间窗口让数据从 DRAM 返回缓存，反而会变成致命延迟。

6.2 判据二：工作集是否远超缓存

流式写适合的是“写完就扔”的数据。如果你处理的是 10GB 的文件流、视频帧的连续编码、大规模数组初始化，工作集远大于缓存，普通 store 的 RFO 不但多读，还会把缓存占满。这种时候流式写几乎必定占优。

反过来说，如果数据总量很小，比如几十 KB，普通 store 重复读缓存行的开销可以被 L1/L2 吸收，RFO 只发生一次，后续写都是缓存命中。流式写反而因为绕过缓存导致频繁访问 DRAM，性能直线下降。

6.3 判据三：是否跨 cache line 且能凑满整行

_mm_stream_si128 一次写 16 字节，一个缓存行是 64 字节。如果连续访问 4 个 16 字节对齐的地址，正好合并成一行，这是最优情况。如果每写 16 字节后跳到很远的地址，写合并缓冲区会被迫把部分行冲刷出去，读效果就会打折扣。

所以面对稀疏更新场景，比如随机更新一个数组的某些位置，流式写反而不合适。这种情况不如用普通 store，让缓存先聚合局部更新，再由缓存一致性协议处理脏行回写。

6.4 多核与 NUMA 的补充

在多线程场景下，流式写还有一个容易被忽略的问题：多个核心如果同时写同一个 64 字节缓存行的不同部分，即便用的是流式写，也可能产生严重的 false sharing 现象。原因在于写合并缓冲区的粒度仍然与缓存行一致，多个核的写入如果映射到同一缓存行，会产生伪共享竞争。

我建议在分配缓冲区时，按线程数把数据按缓存行对齐切分，或者让每个线程独占完整缓存行。例如：每个线程的起始位置用 posix_memalign 对齐到 64 字节，处理长度也尽量是 64 的倍数。这样能避免很多线程竞争。

另外，NUMA 架构下，线程最好在分配内存的本地节点上运行。流式写缓解不了远端内存延迟，反而可能因为绕过缓存，让 NUMA 带来的远端访问代价更加暴露。你要是发现多线程加速比不对劲，先检查线程亲和性和内存分配策略。

7. 踩坑记录：从段错误到内存序错乱

7.1 未对齐地址导致的“狗牙”问题

我第一次大规模使用 _mm_stream_si128 时，直接在 malloc 出来的数组上跑，结果程序偶发段错误。原因就是 malloc 在某个分配大小下只返回了 16 字节对齐，但我在结构体里偏移了 8 字节，导致目标地址只有 8 字节对齐。

解决方案很简单：分配时用 _mm_malloc 或者对结构体字段加 alignas(16)。检查是否对齐，可以用 ((uintptr_t)ptr % 16) == 0，在调试阶段断言一下，能避免很多隐藏故障。

7.2 忘记 sfence 导致的数据“丢失”

另一个常见坑是写完流式数据后，立刻在主线程里用普通指针去读这段数据。因为流式写没有进入缓存，也没有立即刷新到一致性域，你可能会看到老数据，好像写入“丢失”了。这种情况在单线程里看起来像 bug，在多线程里则表现为随机数据错误。

解决方法是：所有流式写之后，按需调用 _mm_sfence()。如果你想确保后续所有读写都越过这条线，就用 _mm_mfence()，不过它的代价更高。大多数场景用 _mm_sfence() 就够了。

7.3 与 malloc/free 混用的崩溃

使用 _mm_malloc 时需要配套使用 _mm_free，不要和普通 free 混用，否则可能崩溃或泄漏。原因是 _mm_malloc 在内部可能调整了指针，返回的地址并不是原始堆块地址。这个问题在项目里很容易藏着，尤其是代码风格比较乱的模块。

如果项目统一使用 C++，还可以考虑 std::vector 配合 allocator，让内存生命周期自动管理，减少手动释放的失误。

7.4 调优建议：先确认是 Memory-Bound 再下手

最后一条看起来像废话，却是最实用的：不要在没有确认 Memory-Bound 之前就神化 _mm_stream_si128。

先用工具量化，比如：

bash复制perf stat -e task-clock,instructions,cycles,branches,branch-misses ./your_program

观察 instructions per cycle，如果很低，再查看 stalled-cycles-backend。只有确认后端访存停顿严重，才值得去优化存储指令。否则把代码可读性搞得复杂，收益却微乎其微。

我习惯的决策流程是：

1. 先看是不是数据量大、写后不读；
2. 再查普通 store 是否承担了过多 RFO 流量；
3. 小范围替换并做 A/B 测试；
4. 测试通过，再决定要不要推广到整个代码库。

把这个流程沉淀下来，你在任何 Memory-Bound 算法上都不会走偏。_mm_stream_si128 只是一个工具，它真正的作用是提醒我们：性能优化的本质，是减少那些“可有可无”的数据搬运，而不是一味在指令级上抠吞吐。