为何单核心下for循环数组拷贝无法达到CPU-RAM峰值带宽？

为什么实际带宽远低于理论峰值？ #

1. 单通道内存的理论值与实际值差距 #

3200MT/s单通道的25GB/s是理想突发传输峰值，但实际中内存控制器的地址解码、CAS延迟、命令调度开销会吃掉15%-20%的带宽，Zen2的单通道内存控制器本身就存在固有损耗，不可能跑满理论值。

2. 内存请求并行度不足 #

你的单核心循环虽然用了256位向量指令，但单核心的Load/Store Queue（LSQ）深度有限（Zen2为72条目），无法发起足够多的内存请求喂饱内存控制器。内存的突发传输需要持续的请求队列支撑，单核心的并行请求数不足以充分利用内存的连续传输能力。

3. 写分配策略带来的额外内存开销 #

你代码中用3x系数计算带宽，认为写回会触发额外加载，实际场景中：malloc分配的是匿名零页，第一次写入target时会触发写复制（COW），加载零页到缓存后再修改；当数组超出缓存容量后，每次写target都会触发写分配——先加载target对应的空缓存行（从内存读），再写入，最后脏缓存行写回。这种模式让内存控制器同时处理读+写请求，进一步降低有效带宽。

4. OpenMP多核心的竞争瓶颈 #

单通道内存控制器由所有核心共享，多核心并行访问时会产生请求竞争，加上Zen2的CCX间内存访问存在延迟，即使绑定核心也无法完全消除竞争开销，所以18GB/s是多核心并行下的合理上限，但仍受限于单通道物理瓶颈。

优化方案：接近峰值带宽的实操方法 #

1. 使用非临时存储（NT Store）绕过缓存 #

用_mm256_stream_pd指令直接写入内存，避免写分配的额外读操作，同时不污染缓存，减少内存流量（从3x降到2x），还能让内存控制器更高效处理连续写请求。修改循环代码如下：

#include <immintrin.h>
// ... 其余代码不变
for (size_t i = 0; i < n; i += 4) {
    __m256d val = _mm256_loadu_pd(&source[i]);
    _mm256_stream_pd(&target[i], val);
}

编译时保留-O3 -march=native参数，单核心带宽可提升至20GB/s左右。

2. 分配对齐内存 #

用posix_memalign或aligned_alloc分配64字节对齐的内存，确保向量指令访问的内存地址对齐，避免跨缓存行的访问开销：

double *source, *target;
// 64字节对齐，对应Zen2的缓存行大小
posix_memalign((void**)&source, 64, n * sizeof(double));
posix_memalign((void**)&target, 64, n * sizeof(double));

3. 优化OpenMP线程绑定 #

设置OMP_PROC_BIND=close和OMP_PLACES=cores，让线程绑定到同一CCD内的核心，减少跨CCX的内存访问延迟，多核心带宽可提升至22-23GB/s（接近单通道理论峰值的90%）。

4. 硬件层面优化（可选） #

如果是台式机，可在BIOS中降低内存CAS延迟、优化时序参数，进一步挖掘内存的实际带宽潜力。

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