AVX2流式存储未提升性能的原因分析

这种情况我之前在优化AVX2工作负载时也碰到过好几次，流式存储（也就是非临时存储，比如_mm256_stream_ps/_mm256_stream_si256这类指令）没起作用，通常逃不开这几个原因：

• 数据被快速复用，缓存反而帮倒忙
  流式存储的核心逻辑是告诉CPU：“这块数据写完后短期内不会被读取”，所以CPU会跳过缓存，直接把数据写入主存，避免占用缓存空间。但如果你的代码在执行流式存储后，很快又要读取这些数据（比如下一个循环就用到了刚写入的数组元素），那CPU就得重新从主存加载数据——这比从缓存读慢得多，反而抵消了流式存储的收益，甚至可能让性能更差。

• 存储本身不是性能瓶颈
  你提到执行时间大部分被内存操作占用，但可能加载（Load）才是主要瓶颈，存储（Store）本身已经被CPU的写合并（Write Combining）机制优化得很好了。写合并会把多个小的存储操作合并成一个更大的总线事务，已经能高效利用内存带宽。如果你的工作负载是读多写少，或者存储操作的吞吐量本来就没到内存总线的上限，那换流式存储自然看不到明显提升。

• 内存地址没对齐到要求的边界
  AVX2的流式存储对内存地址的对齐要求很严格——需要对齐到32字节（AVX2向量的大小）。如果你的目标数组没有正确对齐（比如用普通malloc分配，没指定对齐属性），CPU会自动退化成普通的存储操作，根本不会触发流式存储的优化逻辑。你可以检查一下数组的分配方式，比如用_mm_malloc(..., 32)或者alignas(32)关键字来确保对齐。

• 编译器优化“抵消”了你的手动操作
  在O2/O3这类高优化级别下，GCC、Clang这类编译器会自动分析你的内存访问模式。如果编译器判断流式存储的使用不符合最优缓存策略，可能会把你的_mm256_stream_xxx调用优化回普通的_mm256_store_xxx，或者调整内存操作的顺序，导致流式存储的效果完全没体现出来。你可以查看编译后的汇编代码，确认vmovntps/vmovntdq这类流式存储指令是否真的被生成了。

• 硬件或系统层面的限制
  比如你的CPU虽然支持AVX2，但内存控制器已经被读写操作占满（比如多线程场景下，所有线程的内存操作已经把总线带宽用满了），这时候单线程改用流式存储也没法提升整体性能。另外，极少数老型号x86 CPU可能不支持写合并，不过现代CPU基本都不存在这个问题。

内容的提问来源于stack exchange，提问作者rohitsan