尝试用OpenMP不同分块大小规避false-sharing，为何性能反而减半？

分析与解答 #

1. 默认调度的天然优势 #

OpenMP默认的static调度（绝大多数实现未指定调度类型时默认采用）会将整个循环均匀且连续地分割给各个线程。比如8线程处理6.4亿元素时，每个线程会拿到连续的8000万元素块。这种连续内存访问能最大化利用CPU的缓存预取机制——CPU会自动预取后续连续内存块到缓存，让线程几乎无需等待内存加载，读取a和b的效率极高。

2. 手动小分块破坏了数据局部性 #

你设置的分块大小为64字节 / 4字节 = 16个int32_t，即每个线程每次仅处理16个连续元素。这种极小分块会引发两个关键问题：

• 缓存预取失效：CPU预取的缓存行还未被充分利用，线程就切换到下一个不连续的分块（static, chunk模式下分块会循环分配给线程，如线程0拿块0、8、16...，线程1拿块1、9、17...），预取缓存行中的大部分数据未被利用，白白浪费内存带宽。
• 缓存命中率暴跌：线程处理的内存区域分散，CPU缓存无法有效保留常用数据，频繁出现缓存 miss，不得不从主存重新加载，大幅增加操作延迟。

3. 你的场景不存在false sharing问题 #

false sharing的核心是多个线程同时写入同一缓存行的不同元素，但在你的代码中：

• 默认调度下，每个线程处理连续的大区块，写入c的区域同样连续且独占——线程0写c[0..N-1]，线程1写c[N..2N-1]，以此类推。向量是连续分配的，现代分配器会做缓存行对齐，区块边界自然对齐到缓存行，根本不会出现多线程写同一缓存行的情况。
• 手动设置小分块反而可能让线程写入区域分散，但本质上false sharing并非当前场景的性能瓶颈，优化方向完全错误。

4. 总结 #

你的优化属于画蛇添足：默认调度已完美利用数据局部性和缓存预取，而强行设置极小分块反而破坏了这些核心优势，导致性能暴跌。只有当线程工作区域非连续或存在跨线程写同一缓存行的风险时，才需要调整分块大小规避false sharing，你的场景完全不满足这个条件。

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