用_mm_stream_si128突破Memory-Bound瓶颈：绕过写分配优化内存带宽

做性能优化这行干久了，迟早会碰到这么一种情况：算法逻辑看着贼简单，循环里也没什么复杂运算，可程序跑起来就是慢，CPU占用率还死活上不去。这种问题十有八九是 Memory-Bound（内存受限）——算法在小尺寸数据上跑得飞快，一旦数据量超过缓存容量，性能立刻被内存带宽拖死。我最近在调一个数据处理模块时，就是靠一条SSE指令 _mm_stream_si128，在拷贝、填充这类内存受限场景里获得了明显提速。今天把思路、原理和完整实测过程整理出来，给正在折腾图像处理、大规模数组遍历、数值计算的朋友一个可以直接抄的作业。

1. Memory-Bound 算法的性能瓶颈到底在哪

1.1 什么是 Memory-Bound 算法

先把这个概念捋清楚。代码性能瓶颈按资源类型大致分三类：CPU-Bound（计算密集）、Memory-Bound（内存密集）、I/O-Bound（输入输出密集）。Memory-Bound 的意思很直白：程序把大部分时间都花在从内存读数据、往内存写数据上，而不是花在算术运算上。

怎么判断一段代码是不是 Memory-Bound？我常用的土办法是看两件事。第一，循环体里几乎没什么浮点运算或整数运算，就是“搬数据”；第二，用 perf stat -e cycles,instructions,cache-misses 跑一下，如果 IPC（每周期指令数）明显低于正常水平，同时 cache-misses 高得吓人，那基本就是内存子系统在拖后腿。举个典型例子：一个 64MB 的数组做逐元素累加，64MB 已经超过大部分 CPU 最后一级缓存（LLC）的大小，CPU 再快，也得等着内存把数据一口一口喂进来。

这类算法的共同点就是：计算量小、访存量巨大，性能天花板是内存带宽，而不是主频。所以怎么减少内存流量、怎么让内存访问更高效，就成了优化的核心方向。

1.2 一个容易忽略的隐藏开销：写分配（Write-Allocate）

很多人优化时只盯着读数据，觉得“内存慢主要是读慢”，写操作反正就是写一下，能有多大事？这里藏着一个大多数人都忽略的坑：现代 CPU 的缓存写策略，普遍是 write-allocate（写分配）。

什么意思？当一个普通 store 指令要写入的内存地址在缓存里不存在时，CPU 不是直接把数据写到内存就完事了，而是会先把包含这个地址的整个缓存行从内存读回来，放到缓存里，然后再修改这一行。这个机制叫 read-for-ownership（为所有权而读）。也就是说，原本只打算写 16 字节，实际内存控制器看到的工作量是一个缓存行的读加上一个缓存行的写。对 64 字节的缓存行来说，有效“流量”瞬间被放大。

这种开销在“写新数据”的场景里尤其冤枉。比如你往一个 64MB 的目标数组里填结果，目标数组的内容你根本不关心，但 write-allocate 策略还是会傻乎乎地把每一行先读进缓存再覆盖。等于你只想要个空房间，系统却先把旧家具搬进来、再让你把新家具堆上去。本来写 64MB 的数据，实际产生的内存流量可能接近 128MB，白花了一半带宽。

1.3 什么场景适合上 streaming store

知道了上面的原理，答案就出来了：如果能找到一种“写内存但不经过缓存”的特殊写指令，让 CPU 别去干“先读再写”的傻事，那在 Memory-Bound 场景里就能省掉大量内存流量。_mm_stream_si128 就是干这个的。

但我得先把适用条件说清楚，避免你拿去乱用反而变慢。我总结下来同时满足以下几条才值得用：

• 确实是 Memory-Bound：算法瓶颈在内存带宽，CPU 计算单元明显吃不饱。
• 数据规模要超过 LLC：如果数据量很小，全程在缓存里跑，streaming store 反而因为绕过了高速缓存而变慢。
• 写入的数据近期不会被读回来：这是 streaming store 的隐含代价——写完不留缓存，过一会儿马上读，等于又去内存拿一次，亏到姥姥家。
• 写入模式尽量连续：streaming store 依赖 CPU 的 write-combining 缓冲合并连续写，如果是每个元素随机跳到不同内存地址，效果会大打折扣。

这四个条件都满足，再看下面的原理和实操才有意义。

2. _mm_stream_si128 是干什么的

2.1 指令与 Intrinsic 接口

_mm_stream_si128 是 SSE2 指令集提供的一个存储类 intrinsics，定义在 <emmintrin.h> 头文件里。原型如下：

c复制#include <emmintrin.h>

void _mm_stream_si128(__m128i *p, __m128i a);

它对应三条汇编指令中的 movntdq（Move Non-Temporal DQword）。nt 就是 non-temporal（非临时）的意思，也就是明确告诉 CPU：这数据我不打算短期再读，不用费劲留缓存了。

用的时候注意，目标地址 p 必须 16 字节对齐，否则会直接崩溃或触发总线错误，这点后面在避坑部分细说。

同类指令也很好认：_mm_stream_si32 对应 movnti 写 32 位整数；_mm256_stream_si256 是 AVX 版本，对应 vmovntdq；AVX-512 还有 _mm512_stream_si512。换到 ARM 平台，对应的概念是 NEON 的 non-temporal store，但行为细节不太一样，这里先不展开。

2.2 streaming store 与普通 store 的执行路径对比

把两条指令的执行路径摆在一起，差异就很直观了。

普通 store（如 _mm_store_si128）路径：

1. 检查地址在 L1/L2/L3 缓存是否命中。
2. 未命中时触发 write-allocate，把整个缓存行从内存读回缓存。
3. 在缓存行中修改对应字节，标记为 dirty。
4. 等待缓存行最终被淘汰或显式写回时，才把数据写进内存。

streaming store（如 _mm_stream_si128）路径：

1. 不检查缓存是否命中，直接把数据送入 write-combining buffer（写合并缓冲）。
2. 缓冲区里的数据在合适时机被合并，一次性发往内存控制器。
3. 不回写缓存，不污染 L1/L2/L3。

也就是说，streaming store 把“写内存”这个动作从“先读一行 + 再写一行”简化成了“直接写一行”。对纯写操作为主的 Memory-Bound 算法来说，内存流量直接砍掉一部分，带宽自然就腾出来了。

2.3 write-combining 的合并效应

streaming store 能快，除了省掉 write-allocate 的读，还依赖一个叫 write-combining（写合并）的硬件机制。

CPU 内部有几个容量很小的写合并缓冲区，专门用来收集这种 non-temporal 写。当程序连续执行多条 movntdq 时，如果写入的地址是相邻的，缓冲区会把多个 16 字节的碎片数据拼成完整的 64 字节缓存行事务，再一次性交给内存控制器。内存控制器最擅长的就是处理整行、整批的传输，碎小的写入反而会浪费总线事务。

所以你会发现，循环挨个写数组的 streaming store 版本，比同样循环但每次跳一个固定间隔写的版本快得多。前者能充分利用合并效应，后者会把写合并缓冲区的效率彻底打碎，甚至因为缓冲频繁冲刷变得比普通 store 还慢。

2.4 什么场景值得用，什么场景反而拖后腿

为了让你不用每次都在心里权衡一遍，我把判断矩阵直接列出来：

一句话总结：写大块、连续、短期不读的数据，才是 _mm_stream_si128 的舒适区。

3. 实操：用 _mm_stream_si128 重写内存拷贝

理论说了一堆，不上手跑一遍总觉得心里没底。这一节我用一个最典型的内存受限操作——大数组内存拷贝，从零到一实现三个版本做对比：普通循环拷贝、SSE 普通 store 拷贝、SSE streaming store 拷贝。

3.1 测试环境与准备

先说测试环境，方便你对比数据时有个参照：

• CPU：Intel Xeon E5-2697 v3，DDR4-2133 双通道
• 系统：Linux，Kernel 5.15
• 编译器：GCC 9.4，编译选项 -O2 -msse2
• 测试数据量：64MB，远大于该平台约 20MB 左右的 LLC

为什么选 64MB？因为只有数据量超过最后一级缓存，才能保证测量的是真实内存带宽，而不是缓存命中后的假象。数据量太小的话，普通 store 因为缓存全程命中，反而会显得特别快，这测出来的结论没有任何参考价值。

内存分配我用 posix_memalign，按 64 字节对齐分配源数组和目标数组。_mm_stream_si128 要求 16 字节对齐，但我习惯直接按 64 字节对齐，顺手也满足了 AVX 指令的潜在需求，后面想换 _mm256_stream_si256 都不用改分配代码。

3.2 三个版本代码实现

先定义公共参数和计时函数：

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <time.h>
#include <emmintrin.h>

#define TOTAL_BYTES (64 * 1024 * 1024)
#define N (TOTAL_BYTES / 16)

static double now_ms(void) {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ts.tv_sec * 1000.0 + ts.tv_nsec / 1e6;
}

第一个版本，最朴素的标量拷贝，一次拷一个 64 位整数：

c复制static void copy_scalar(const uint64_t *src, uint64_t *dst, size_t n) {
    for (size_t i = 0; i < n; i++) {
        dst[i] = src[i];
    }
}

第二个版本，SSE 普通 store。每次用 _mm_load_si128 读 16 字节，再用 _mm_store_si128 写 16 字节：

c复制static void copy_sse_plain(const __m128i *src, __m128i *dst, size_t n) {
    for (size_t i = 0; i < n; i++) {
        __m128i v = _mm_load_si128(src + i);
        _mm_store_si128(dst + i, v);
    }
}

第三个版本，只把 store 换成 _mm_stream_si128，load 保持不变：

c复制static void copy_sse_stream(const __m128i *src, __m128i *dst, size_t n) {
    for (size_t i = 0; i < n; i++) {
        __m128i v = _mm_load_si128(src + i);
        _mm_stream_si128(dst + i, v);
    }
}

代码差异就这一行，但行为完全不一样。

主程序里我做了这么几件事：分配并初始化源数组、预热一次、分别测量三个版本、打印带宽数字。核心测量片段大致长这样：

c复制int main(void) {
    __m128i *src = NULL, *dst = NULL;
    posix_memalign((void**)&src, 64, TOTAL_BYTES);
    posix_memalign((void**)&dst, 64, TOTAL_BYTES);

    for (size_t i = 0; i < N; i++) {
        src[i] = _mm_set1_epi64x((long long)i);
    }

    // 预热，确保页面分配完成
    copy_sse_stream(src, dst, N);

    for (int r = 0; r < 7; r++) {
        double t0 = now_ms();
        copy_sse_stream(src, dst, N);
        double t1 = now_ms();
        printf("round %d: %.2f GB/s\n", r,
               (double)TOTAL_BYTES / 1e9 / ((t1 - t0) / 1e3));
    }

    free(src);
    free(dst);
    return 0;
}

我自己跑的时候把三个版本都封装成函数指针，循环里交替测量，取每轮最优值，减少系统噪声。

3.3 科学计时：别被误差骗了

性能测量不是随便记个时间就完事，几个细节做不好，数据根本没法看。

第一，必须预热。大数组第一次访问会触发大量缺页异常，页面分配和清零会混进计时里，严重污染数据。我习惯先跑一次目标函数，把页面都碰过一遍，再开始正式计时。

第二，多次测量取最优。内存子系统受频率变化、后台进程调度影响很大，单次测量波动可能超过 10%。我一般跑 7 轮，去掉前两轮热身结果，从后五轮里取最小值，或者至少取平均值展示。

第三，防止编译器优化掉你的测试代码。拷贝完的目标数据如果一直没被“使用”，理论上编译器无法完全删除 store（因为指针可能是外部可见的），但为了稳妥，我通常在测量结束之后加一个求和或打印，把 dst 里的某个值消费掉，确保整个 store 链路没有被优化掉。

第四，明确带宽口径。下面表格里的数字，我按“搬运的数据规模”计算，也就是 64MB 除以耗时。严格讲一次拷贝的内存流量包含读 64MB + 写 64MB，如果按 stream benchmark 的 add/copy 口径，数值会翻倍。不同文章算法不一样，看的时候先确认口径再比较。

3.4 实测结果与分析

我这台机器上跑出来的典型数据如下：

数字本身只代表我这台测试机，但三个版本之间的差距是很有代表性的。

标量版本慢，一方面是因为编译器自动向量化后依然按普通 store 处理，另一方面是它写目标地址时会触发 write-allocate，每一行都得先读进缓存再写，内存流量实际接近“读源 64MB + 读目标 64MB + 写目标 64MB”。

SSE 普通 store 版本把单次访问宽度从 8 字节提到 16 字节，指令数少了，访存效率高了，但还是绕不开 write-allocate，所以提升有限。

streaming store 版本直接把写分配过程砍掉，目标地址不再“先读再写”，同时连续写又让写合并缓冲区把 16 字节的写入拼成 64 字节整行事务，内存控制器的传输效率更高。算下来从 64MB 拷贝的理想流量来看，普通 store 多花了一笔冤枉的读流量，streaming store 把这笔流量彻底干掉，所以提升最明显。

补充一个很有意思的对照组：我把同样的目标数组改成 memset(dst, 0, TOTAL_BYTES)，也就是纯填充场景，结果 glibc 的 memset 在 64MB 这个大尺寸下，带宽也跑到了 11GB/s 左右，跟我的手写 streaming 版本差不多。这其实不奇怪，因为 glibc 内部对超大尺寸的 memset/memcpy 本来就会切换到 non-temporal store 路径，用的就是同一条 movntdq 指令。换句话说，你平时用的标准库函数，底层已经偷偷在用这个优化了。

4. 进阶：streaming store 在实际项目中的典型用法

拷贝和填充是最容易演示的场景，但实际项目里能用到 _mm_stream_si128 的地方远不止这些。挑几个我真正在代码里用过的场景说。

4.1 图像处理：无处安放的输出像素

图像处理是 Memory-Bound 算法的重灾区。一张 4K 照片，RGB 三通道，光是把原始像素数据转成灰度图或者做一次缩放，就要读写几千万个字节。很多图像库的处理流程是：读原图 → 逐像素计算 → 写入输出缓冲。

输出缓冲这个“写”的动作，天然就适合 streaming store。因为输出缓冲在写完之后，通常会被立即编码成文件、压缩或者交给 GPU 上传，在 CPU 缓存里留着它没有任何价值，反而会把原图数据从缓存里挤出去。我在一个图像缩放模块里把最终输出循环里的 _mm_store_si128 全部换成 _mm_stream_si128 之后，整体耗时降了大约 12%——不算夸张，但免费用，何乐而不为。

4.2 矩阵计算：把结果写回大数组

做矩阵乘法或者逐元素运算时，如果结果矩阵很大，写回过程同样会触发 write-allocate。尤其是那种“分块计算、集中写回”的写法：内层循环把一块结果算完，然后一次性写到结果矩阵的对应位置，这正好是 streaming store 的理想模式。

我踩过的一个合适的例子是稀疏矩阵的某种预处理，需要把一个几千万行、每行几十个非零元素的中间结果平铺到大数组里。因为每行的写入地址是连续的、行与行之间也是顺序的，而且这个中间结果写完之后马上被另一个核心读取前还有一段距离，用 _mm_stream_si128 批量写回，实测写入时间省了将近 20%。

4.3 与 prefetch 搭配：搭一条内存流水线

streaming store 管的是“写”，但数据总得先读进来才能写。对于先读后写的算法，我习惯把 streaming store 和非临时预取 _mm_prefetch 搭配起来用。

思路大概是：循环里一边用普通 load 读取源数据，一边用 _mm_prefetch 提前把后面几十个迭代要用的源数据拉到缓存里，写则用 _mm_stream_si128 直接落内存。这样读和写分别走两条路径，读有预取撑着不至于停顿，写又不用跟读抢缓存，整条循环就像一条流水线，把内存延迟尽量藏起来。

prefetch 的距离需要按平台微调。我在这台 Xeon 上试过，提前 512 字节左右效果最好；距离太近等于没预取，太远又可能把数据提前挤出去。这个没有通用公式，只能实测。

4.4 影响范围：哪些项目值得做

从更宏观的视角看，_mm_stream_si128 这类 non-temporal store 几乎渗透在每一个对性能有要求的底层库里：

• 高性能计算里的矩阵运算库（BLAS/LAPACK）在处理大矩阵写回时会用；
• 图像视频库在帧处理管线的输出环节会用到；
• 本地文件系统或内存文件系统在做大块数据拷贝时会用到；
• 甚至操作系统内核在清零大块物理页框时，也会考虑 non-temporal 操作。

对你的项目来说，判断标准还是回到开头那几条：内存受限、数据量大、写后不久不会读、写地址连续。一旦命中这些条件，改动成本基本就是替换一个 store 指令，收益却可能达到两位数百分比，性价比相当高。

5. 常见问题与避坑清单

优化这种东西，收益是真的，坑也是真的。最后把这几年用 streaming store 踩过的坑系统列一遍。

5.1 对齐：movntdq 的硬性门槛

_mm_stream_si128 要求目标地址 16 字节对齐，这一点没有商量余地。如果你传一个没有对齐的地址进来，轻则触发 segmentation fault，重则在某些系统上产生总线错误，排查起来特别让人抓狂。

常见的对齐来源有三类：posix_memalign 分配的内存、_aligned_malloc（Windows）、或者 C++ 里 alignas(16) 修饰的数组。千万别图省事用普通的 malloc 然后手动偏移当 16 字节用，你能保证偏移量，但要保证整个对象生命周期内偏移始终存在，很容易出幺蛾子。

5.2 顺序与可见性：什么时候必须 sfence

movntdq 是弱顺序指令，它不保证其他处理器核心或者外部设备能立刻看到写入结果。如果你在写完 streaming 数据之后，马上依赖另一个线程去读取这些数据，必须加上内存屏障。

标准做法是在所有 streaming store 之后调用 _mm_sfence()，它会保证 SFENCE 之前的写操作对其他核心可见，同时不把 streaming store 的绕过缓存效果抵消掉。如果用的是 _mm256_stream_si256 等 AVX 版本，同样可以配合 _mm_sfence()。

我自己踩过一次：多线程程序里一个线程用 streaming store 填充任务缓冲，另一个线程忙等数据就绪，因为没有 sfence，结果等了几千个循环才看到数据，性能反而崩了。加一个 _mm_sfence() 之后一切正常。

5.3 数据量不够大，别硬上

streaming store 的适用尺寸不是我拍脑袋定的，背后逻辑很简单：如果写入数据远小于 LLC 容量，普通 store 写完基本都能命中缓存，后续读还能享受缓存加速。streaming store 把数据直接踢到内存，下次再读又要走一遍内存，平白多花一次访存时间。

经验阈值大概是这样：写入总量连 LLC 一半都不到，就别用 streaming store；超过 LLC，才值得考虑。像 64MB 这种远超 LLC 的数据量，就是标准的使用场景。

5.4 效果不升反降的排查清单

如果你按上面方法改了代码，发现性能没有提升甚至反而下降，按这个顺序排查：

其中 NUMA 问题是很多人忽略的：线程在一个节点上跑，目标 buffer 却分配在另一个节点的内存上，跨节点访问内存带宽会缩水严重，此时 streaming store 的优化效果会被掩盖很多。

最后分享一个我自己的使用习惯：每次优化前先写一个最小的 benchmark 验证带宽差异，确认平台特性之后再动正式代码。因为不同 CPU 的 write-allocate 策略、write-combining 缓冲大小、LLC 大小都不一样，网上别人跑出的结论只能当参考，真正能不能提速，永远要拿自己机器上的数字说话。优化这事，数据永远比感觉可靠。