为何多次小memcpy操作比单次大memcpy操作更快？

哦，这个现象确实有点反直觉——毕竟我们一直默认memcpy天生擅长处理大块数据！不过结合你的测试场景和代码细节，这里面其实有几个关键的性能影响因素，我来帮你拆解清楚：

1. 缓存局部性与TLB命中率的核心差异 #

你的测试总数据量是800MB（100个double×1e6次=8e8字节），这个尺寸已经远超普通CPU的L3缓存（通常在几MB到几十MB），甚至超过了TLB（虚拟地址转物理地址的缓存）的覆盖范围：

• 单次大memcpy：复制整个800MB连续块时，CPU需要不断把内存数据加载到缓存再写入目标地址，但块太大导致缓存频繁被打满，触发大量缓存miss；同时TLB无法容纳这么多内存页的映射，会频繁触发TLB miss（每次miss都要去内存读取页表，开销极大），两个因素叠加直接拖慢了速度。
• 多次小memcpy：每次只复制800字节（100个double），这个尺寸远小于L1/L2缓存（L1通常32KB左右，L2是256KB），所以每次复制的源和目标数据都能完全被缓存住，缓存命中率接近100%；同时800字节只占1个内存页（4KB），TLB命中率也极高，不需要频繁刷新页表，自然速度更快。

2. 编译器的差异化优化策略 #

现代编译器（比如VC++ 2017和ICC 2018）会根据memcpy的复制尺寸动态调整优化逻辑：

• 对于小尺寸memcpy，编译器通常会直接内联SIMD指令（比如SSE、AVX）完成复制，完全避免函数调用开销，而且SIMD指令可以一次性复制多个double，效率拉满。
• 对于超大块memcpy，编译器一般会调用标准库的通用memcpy实现，这个实现是面向全场景的，可能没有针对你的特定硬件做极致优化，或者在处理超大块时的预取策略不如小批量操作高效（毕竟预取的缓存空间有限）。

3. 内存布局的潜在影响 #

看你的代码，y里的每个y[i]都是单独new出来的小内存块——如果你的多次小memcpy是把x的连续小块写入这些分散的y[i]，目标地址的分散反而可能帮助内存控制器并行处理多个小请求，更好利用内存带宽；而单次大memcpy是连续写入一个大块，可能会触发内存的“突发传输”瓶颈，当内存带宽饱和时，连续大块的写入效率反而不如分散的小请求。

验证建议 #

如果你想进一步确认这些原因，可以试试：

• 调整sz和nm的数值，保持总数据量不变（比如sz=1000，nm=1e5），看看单次和多次memcpy的耗时变化——当单次复制的块尺寸降到缓存能容纳的范围时，两者的耗时差距应该会缩小。
• 检查内存对齐情况：确保x、z1、y[i]的内存对齐到SIMD指令要求的边界（比如16字节或32字节），不对齐的memcpy会额外增加开销。
• 查看编译后的汇编代码，对比单次和多次memcpy对应的指令差异，确认是不是编译器内联SIMD指令导致的性能差距。

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