内存受限优化：用流式存储指令绕过缓存，提升写入带宽

写这篇文章是因为我实际遇到过一个很典型的场景：某个算法的逻辑已经精简得不能再精简了，压栈、循环展开、内存池都上了，但性能始终卡在某个数值上不去。后来用 perf 一看，CPU 的计算单元大量空闲，内存控制器却早已饱和。这就是典型的 Memory-Bound（内存受限）问题。当时我沿着数据写入路径追下去，发现一个常被忽略的瓶颈：普通 store 指令的写入分配（Write Allocate）行为，会在不知不觉中让内存带宽白白浪费一半。把 _mm_stream_si128 这类流式写入（Streaming Store）换上之后，同样的代码运行时间有了肉眼可见的下降。这篇文章就把这条优化路径从头到尾拆开讲清楚。

_mm_stream_si128 是 SSE2 里的一条非临时存储（Non-Temporal Store）指令，专门用于绕过 CPU 缓存层次结构、直接向内存发起写入。它解决的不是"计算慢"，而是"内存访问模式不合理"导致的带宽浪费。本文适合正在做底层性能调优、研究 SIMD 优化、或者被大数据集处理速度折磨的开发者阅读。

1. 内存受限的核心矛盾：CPU 在等内存，而不是内存被算满

1.1 先判断你的算法到底是不是 Memory-Bound

很多朋友一上来就写 SIMD 版本，其实第一步应该先判断瓶颈类型。内存受限类算法有一个非常直观的特征：单位数据处理所需的计算量极低。比如大规模数组清零、数据拷贝、像素填充、灰度图二值化、内存池批量初始化，这些操作每个元素平均不到一次算术运算，却要读写大量字节。

判断方法不复杂。用性能工具采样一次，如果 CPU 的算术逻辑单元利用率很低、绝大部分时间卡在内存子系统请求上，LLC（Last-Level Cache）Miss 率又很高，基本就可以认定是 Memory-Bound。我习惯用 Intel VTune 里的 Memory Access 分析，或者直接看 perf stat 输出的 LLC-load-misses 和 offcore_response 指标。当有效内存带宽接近理论峰值、同时 CPI 高得离谱时，计算已经不是瓶颈了，你优化循环展开收益也很有限，真正该优化的是访存路径本身。

还有更简单的经验判断：当数据规模明显大于 LLC 容量时，算法运行时间随数据量线性增长；把数据规模缩小到能够完全放进 L2 时，同样的代码能快上几倍甚至十几倍。这个落差越大，说明越依赖内存带宽。

1.2 常规存储指令的隐藏成本：缓存写入分配

问题藏在普通 store 的硬件行为里。x86 的缓存一致性协议采用写回（Write-Back）策略，CPU 执行一条 movntdq 或 movdqa 存储指令时，如果目标地址不在 L1 Cache 中，硬件并不会直接把数据送到内存，而是先发起一个读所有权请求（Read For Ownership, RFO），把对应缓存行完整地从内存读到 L1，然后修改该缓存行，标记为脏，等将来逐出时才把整行写回内存。

对于"完整覆盖整块缓存行"的写入场景，这次 RFO 是完全多余的。你本来就要把这一整行 64 字节全部覆盖，为什么还要先把它从内存读一遍？这就等于一次写入操作实际占用了一次读和一次写的带宽。在内存带宽接近饱和时，50% 的额外读开销会直接让有效吞吐量腰斩，尤其在大规模 memset、图像填充这类数据拷贝量大的例程里，影响极其明显。

以 64 字节缓存行为例：普通 store 写 64 字节，内存控制器实际完成的工作是读 64 字节加写 64 字节。而流式存储只写 64 字节，无需预读。内存控制器吞吐量不变的情况下，有效写带宽可以提升将近一倍。

1.3 经典例子：你以为 memset 已经足够快了吗

我最早意识到这个问题，是在优化一段批量初始化内存的代码。原始版本就是最普通的 for 循环赋值，后来换成了 SSE 的 _mm_store_si128，但性能并没有比编译器自动向量化好太多。数据量是 512MB，我的测试机内存带宽大约 25GB/s 的读取水平。理论上 memset 512MB 只需要约 20ms，但实测普通 SSE store 版本始终在 30ms 附近徘徊。

问题不在算力，而在 RFO。目标缓存行不在缓存里，每次 _mm_store_si128 触发读分配，内存控制器背地里多读了一次同样的数据。后来把 _mm_store_si128 换成 _mm_stream_si128，时间立刻降到 22ms 左右。这条指令不申请缓存行、不发起 RFO，直接通过写合并缓冲把数据推给内存控制器。看似只是换了一个 intrinsic，背后却把"写前先读"这个隐藏操作彻底绕开了。

2. 流式指令的底层逻辑：_mm_stream_si128 把数据“绕”过的缓存路径

2.1 movntdq 指令与写合并缓冲区

_mm_stream_si128 编译后对应的指令是 movntdq，其中的 NT 表示 Non-Temporal，即"非临时性"。它暗示硬件：这份数据不会被短时间内重复使用，不要浪费缓存容量。处理器执行这条指令时，不会执行常规的缓存分配流程，而是把数据直接送入一个叫写合并缓冲（Write Combining Buffer, WCB）的部件。

WCB 是一个小容量缓冲区，CPU 会把连续写入的多个部分缓存行合并成完整缓存行，再以整行粒度批量写回内存。对于顺序写入模式，WCB 的合并效率非常高。你可以把它理解成快递站里的大包裹合并：零散的几个小包裹不单独派送，凑满一整车再发，省去了多次往返的运输开销。

也正因为不分配 L1/L2，写出的数据不会污染缓存。对于一次性消费的数据流，这反而是优点。配合 movntdq 的还有非临时加载指令 _mm_stream_load_si128（movntdqa），用于读取不会被重复访问的大块数据，同样避免数据占用缓存。

2.2 指令族与对应的 intrinsic

流式存储并不只有 _mm_stream_si128 一个，它是一整个家族：

用的最多的是 128 位和 256 位版本。写代码时记得包含头文件 <emmintrin.h>（SSE2）、<immintrin.h>（AVX/AVX-512）。如果平台支持 AVX2，优先使用 _mm256_stream_si256，单条指令处理的数据量翻倍，对内存带宽的利用也更充分。不过本文核心思路和原理对宽度不敏感，128 位版本足够说明问题。

2.3 弱内存序：流式写入需要 sfence 兜底

流式存储和普通 x86 存储还有一个关键区别：它是弱排序的。普通 store 在 x86 TSO 内存模型下天然按程序顺序被其他处理器观察到，而 movntdq 不遵循这种强排序保证。WCB 中的数据可能延迟、乱序地刷入内存，因此多核场景下，一个线程写入流式数据后，另一个线程读取这些数据时，可能看到不完全一致的结果。

解决办法是执行一条 _mm_sfence()。sfence 会把当前处理器所有已发出的流式写入按顺序刷出到全局可见状态，确保后续操作看到的写入顺序与程序顺序一致。在初始化共享内存、通知其他线程读取等场景，必须在写完之后、发信号之前调用 _mm_sfence()。单线程且后续没有依赖顺序的写入时，也可以省掉这一条，但我个人习惯保留，避免代码被复用进多线程环境后出问题。

3. 动手实操：常见 Memory-Bound 例程的流式改写

3.1 示例一：数组填充改写步骤

我们先从最简单的数组填充开始。原始版本：

c复制void fill_scalar(int32_t *dst, int32_t value, size_t n) {
    for (size_t i = 0; i < n; ++i) {
        dst[i] = value;
    }
}

编译器开 -O3 也会向量化，但默认生成的是普通 movdqa/vmovdqa 存储。我们改成流式版本：

c复制#include <emmintrin.h>

void fill_stream_sse(int32_t *dst, int32_t value, size_t n) {
    __m128i v = _mm_set1_epi32(value);
    size_t i = 0;

    // 主循环：每个迭代写 4 个 int32，共 16 字节
    for (; i + 4 <= n; i += 4) {
        _mm_stream_si128((__m128i *)(dst + i), v);
    }
    _mm_sfence();

    // 尾部
    for (; i < n; ++i) {
        dst[i] = value;
    }
}

这段代码有几个关键点。请确保 dst 按 16 字节对齐，否则 _mm_stream_si128 非法，一般分配函数返回的地址已经满足对齐，但使用 std::align 或分配器时要手工检查。主循环越界风险通过 i + 4 <= n 控制，防止写入越界。尾部的标量写入量很小，一般不超过 3 个元素，性能影响可忽略。

3.2 示例二：内存拷贝与图像区域填充

内存拷贝是常见的 Stream Store 应用到数据搬移的场景。普通实现是两个数组之间逐块拷贝，目标侧没有任何预读价值，所以用流式写非常合适。示例：

c复制void copy_stream_sse(const int32_t *src, int32_t *dst, size_t n) {
    size_t i = 0;
    for (; i + 4 <= n; i += 4) {
        __m128i val = _mm_load_si128((const __m128i *)(src + i));
        _mm_stream_si128((__m128i *)(dst + i), val);
    }
    _mm_sfence();
    for (; i < n; ++i) {
        dst[i] = src[i];
    }
}

图像处理里的"将整个矩形区域置为固定颜色"也是同一套路。很多图像库的 ROI 填充都没有做 SSE 优化，自己手写一个 16 字节对齐的流式填充版本，在大图应用上收益立竿见影。注意图像行宽与行首地址的 16 字节对齐问题，图像数据来自外部格式时经常不是对齐的，需要额外处理。

3.3 处理非对齐地址的正确姿势

实际项目中能拿到完美对齐内存的概率并不高，尤其是图像缓冲区、序列化数据包这类内存块，开头地址不一定恰好 16 字节对齐。直接对未对齐地址调用 _mm_stream_si128 会导致异常或未定义行为，因此需要一个"头对齐—主循环—尾处理"三段式结构。

先处理头部：用标量循环或 _mm_storeu_si128 手动写满前几个元素，直到下一个地址满足 16 字节对齐。再进入主循环，用 _mm_stream_si128 处理对齐的大块数据。最后用非对齐版本或标量循环处理尾部。也就是这样：

c复制void fill_stream_align(int32_t *dst, int32_t value, size_t n) {
    __m128i v = _mm_set1_epi32(value);

    // 头对齐
    uintptr_t addr = (uintptr_t)dst;
    size_t prefix = (16 - addr % 16) % 16 / sizeof(int32_t);
    if (prefix > n) prefix = n;
    for (size_t i = 0; i < prefix; ++i) dst[i] = value;

    // 主循环
    size_t i = prefix;
    for (; i + 4 <= n; i += 4) {
        _mm_stream_si128((__m128i *)(dst + i), v);
    }

    // 尾部
    _mm_sfence();
    for (; i < n; ++i) dst[i] = value;
}

之所以这样做，是因为流式写入一旦中途切换地址对齐方式，代码会变得复杂且容易出错。头尾的少量标量操作对整体性能影响极小。

3.4 什么场景绝对不能盲目替换

流式存储不是万能钥匙。这里必须给朋友们提个醒：数据会在写后不久被再次读取的高频访问场景，不要用流式写。典型反例是循环卷积、图像滤波中间缓冲区、反复迭代更新的矩阵。这类场景的数据写完后马上又被读取甚至多次读取，普通 store 能把这些数据留在 L1/L2 里，后续读取速度极快；改成流式写入等于逼硬件把数据晾在内存里，每次读取都要走完整条内存通路，结果反而慢好几倍。

判断标准就一条：写入的数据在短时间内（纳秒到微秒级别）是否会被重复使用。会，就用普通 store；确定不会，才考虑流式写。

4. 实测数据与性能解读：快慢分水岭在哪

4.1 测试环境和方法

我在一台常见的 x86-64 桌面上做过对比测试，配置为 4 核 8 线程、8MB L3、DDR4-2666 双通道内存。测试对象是 256MB 的 int32 数组填充（共 6.4 千万个元素），分别使用普通标量循环、普通 SSE store、流式 SSE store 三种方案。为了避免缺页中断干扰，测试前先对数组做了一遍预热，把页面全部驻留进内存，再重复执行 10 次取最小值。

计时使用 rdtsc 固定频率时钟换算成毫秒，并排除 _mm_sfence 的等待时间。实际测试里 _mm_sfence 的耗时非常小（微秒级），但严格记录时还是单独标注了。

4.2 大数组测试结果

结果其实很接近理论预期。以 256MB 数组为例：

普通 SSE store 已经比标量快，因为单条指令写入的数据量更大，指令开销减少。但它的提升效果被 RFO 带来的额外读带宽抵消了一部分。流式版本省掉 RFO，直接逼近了纯写操作的带宽极限。换算下来，256MB 在 32ms 内写完，写带宽约 8GB/s。DDR4-2666 双通道内存的理论写带宽在 10-12GB/s 左右，实际去掉内存控制器和刷新开销，8GB/s 已经接近实用上限。

如果把数组做得更大，比如 1GB，差距会进一步拉开。这时候整个数据完全超出 LLC 容量，普通 store 的 RFO 几乎每次都会触发一轮完整的读内存操作，额外读流量更加明显。流式版本的优势更稳定。

4.3 小数组测试结果：缓存优势的反转

换成 1MB 数组（完全能放进 L2），结果完全反转：

在这个规模下，数据写入后虽然程序不用，但整个数组一次性从内存读进缓存，随后全部在缓存内写回。普通 SSE store 在 L2 内部完成整轮操作，速度极快。流式存储反而必须每次穿透到内存，等待 DRAM 周期，所以比普通 SSE store 慢不少。

这说明一个关键问题：选择流式存储不能只看"是不是 Memory-Bound"，还要看工作集大小是否显著大于缓存容量。小数组上强行用流式写入，是典型的负优化。

4.4 多线程下的特殊情况

多线程场景要单独说。流式存储有两个优点：不会污染 LLC、不触发 RFO。当多个线程同时写不同的大数组时，普通 store 的 RFO 会争抢同一内存控制器，而流式写虽然也经内存控制器，却省掉了一半的读流量，整体表现更稳定。我的测试中，8 线程同时各自填充 64MB 独立数组，流式版本总带宽比普通 SSE store 高约 30%。

不过别指望线程数增加能线性提高带宽。内存通道一旦被占满，增加线程只会增加等待。流式写在多线程下的本质优势是降低了每字节数据的总传输量，而不是提升单核峰值带宽。在 NUMA 架构上，还要尽量保证每个线程写自己所在节点对应的内存，否则跨节点访问的惩罚会直接吞噬流式优化带来的收益。

5. 进阶踩坑、边界处理与扩展思路

5.1 对齐问题的深坑：未对齐调用会直接崩溃

_mm_stream_si128 对地址对齐的要求比普通 _mm_store_si128 更严。普通 store 在部分编译器上遇到未对齐地址会退化成多个窄存储或产生异常；movntdq 则要求地址必须是 16 的倍数，否则生成 #GP 异常。在 Linux 上你会看到 SIGSEGV，在 Windows 上可能直接触发系统错误报告。

排查技巧是写一个断言：

c复制assert(((uintptr_t)dst & 0x0F) == 0);

发布版本里可保留这个断言，性能开销可忽略。如果内存地址来自外部库，对齐工作必须前移。还有一种常见情况：使用 std::vector<int32_t> 时，其数据起始地址通常 16 字节对齐，但如果用 reserve 后再 data() 也可能对齐，但绝不保证。最稳妥的是用 aligned allocation，比如 C++17 的 std::aligned_alloc(16, size) 或者 Linux 的 posix_memalign，避免踩坑。

5.2 与内存分配器、大页、NUMA 的交互

流式写入的性能和底层物理页也有关系。普通 4KB 页可能触发较多的 TLB Miss，尤其当数组达到几百 MB 甚至上 GB 时，TLB 压力会拉低访存效率。如果使用 mmap 分配并用 madvise(MADV_HUGEPAGE) 开启透明大页，或者干脆用 2MB 大页，就能显著降低 TLB Miss，让流式写的带宽优势发挥得更彻底。配合流式存储，大页带来的收益比普通 store 更明显。

NUMA 架构下还有一个部署层面的取舍。线程写本地内存时，流式存储省掉的 RFO 同样会减少跨节点传输，但如果线程写的是远端内存，内存访问本身的延迟已经很高，流式优化救不回来。建议用 numactl --membind 或 mbind 把缓冲区绑定到线程所在 NUMA 节点，再做流式写入优化，效果才明显。

5.3 扩展到 AVX2/AVX-512 和流式加载

如果平台支持 AVX2，把 _mm_stream_si128 换成 _mm256_stream_si256 可以进一步提升单次写入的数据宽度。宽指令能减少指令数、提高内存控制器的请求效率，实测在纯写场景往往还有 5% 到 15% 的提升幅度。

c复制#include <immintrin.h>

void fill_stream_avx(int32_t *dst, int32_t value, size_t n) {
    __m256i v = _mm256_set1_epi32(value);
    size_t i = 0;
    for (; i + 8 <= n; i += 8) {
        _mm256_stream_si256((__m256i *)(dst + i), v);
    }
    _mm_sfence();
    for (; i < n; ++i) dst[i] = value;
}

注意 dst 要满足 32 字节对齐。AVX-512 类似，用 _mm512_stream_si512，对齐要求 64 字节。对于内存复制任务，还能搭配 _mm_stream_load_si128 做源数据的非临时加载，完整绕开缓存。两个方向同时用流式指令时，数据从内存出来直接进寄存器，再直接回内存，不占用任何缓存，整个通路最干净。

5.4 判断时机与架构差异的通用准则

我总结了一套通用的判断流程，遇到 Memory-Bound 优化时就按顺序检查：

1. 先确认算法确实是 Memory-Bound，而不是计算受限或延迟受限；
2. 确认工作集大小远大于 L3 容量（通常超过 L3 的 2 到 4 倍再考虑流式写）；
3. 确认写出的数据在短期内不会被重新读取；
4. 确保目标地址对齐（16/32/64 字节按指令宽度来）；
5. 启动多线程或跨 NUMA 部署前，先单核跑通基准；
6. 正式上线前用 perf 验证有效内存带宽是否实际提升，而不是只依赖耗时直觉。

不同 CPU 微架构对非临时存储的实现不完全一致。Intel 近几代的 WCB 数量和合并策略略有差异，AMD 的 Zen 系列也有自己的实现方式。最终是否获益、获益多少，必须以本机实测为准。一个通用结论是：当 RFO 造成的多余读带宽成为瓶颈主力时，流式存储几乎必然有效；当瓶颈在别处，换指令也解决不了。

我个人在实际项目中用 _mm_stream_si128 优化过图像处理、内存池初始化和大批量数据传输三个方向。效果最好的一个案例，是把一段数据搬移逻辑从 110ms 压到了 70ms 左右。但我也会提醒自己：流式写入的收益是高度条件化的，换一个数据集、换一台机器、换一种访问模式，结果就可能完全不同。建议手边准备一个可以随时切换开关的 benchmark 小工具，任何优化都先量化，再上生产，靠数据说话，而不是靠感觉。