OpenMP并行for循环运行速度低于单线程的问题咨询

1. 伪共享是多线程性能暴跌的核心诱因 #

你定义的static int th[8]是8个连续的int值，总共只占32字节，刚好落在x86架构默认的64字节大小的同一个缓存行上。所有线程在循环里执行++th[omp_get_thread_num()]时，哪怕每个线程只修改自己专属的th数组元素，也会因为操作的是同一个缓存行的内容，触发MESI缓存一致性协议的全局同步：任何一个核心修改缓存行内的某一字节，其他核心对应缓存行就会被标记为失效，后续核心要读取自己负责的th元素时，必须等总线把最新的缓存行版本传过来。
这种全局缓存同步的开销远高于你循环本身的计算量：1e6次循环的总计算耗时才10ms左右，光伪共享带来的缓存无效开销就会随着核心数增长线性上升，最终表现为2-8线程时性能直接腰斩。

2. 循环内置的共享变量写入放大了性能损耗 #

你在循环迭代体里反复修改共享的th数组，总共有1e6次跨核心的写操作，每次写都要触发一次全局缓存同步。哪怕你后来把th数组换成静态全局数组，这个本质问题没有任何改变。

3. 当前测试的计算负载过轻，无法覆盖并行固有开销 #

你测的1e6个double元素的循环，总计算量极低：

• 纯连续内存写操作本身就能被单线程的硬件预取机制打满，单线程已经能跑到接近内存写带宽的上限，多线程拆分任务也不会带来带宽收益。这也是你注释掉++th语句后，多线程性能没有明显改善的核心原因——总带宽已经被单线程占满，多开线程只会增加同步开销
• OpenMP并行块本身存在固定开销：静态循环块的调度计算、线程池的唤醒同步、并行区域结束的隐式屏障，这部分开销在VS2015的OpenMP v2.0实现里大概占3-5ms
• 总计算时长才10ms的情况下，固定开销就占了一半以上，多开线程的额外开销只会让总耗时进一步上升

4. 测试流程引入了测量误差 #

你在主函数里的测试顺序是先跑无OMP版本，再依次跑1/2/4/8线程的并行版本。无OMP版本第一次分配动态数组时，会触发大量缺页中断，这部分时间已经被计入耗时；后面的并行版本因为操作系统已经提前为该内存范围分配好了物理页，不存在缺页开销，这也是为什么你测的1线程并行版本（0.0076s）比无OMP版本（0.0109s）更快——根本不是并行的功劳，是测量环境不一致导致的偏差。

• 彻底消除伪共享：把循环里的共享th数组写入逻辑替换为线程私有的局部计数变量，只在循环完全结束、线程退出并行块时，把最终的计数结果写入共享的th数组，从根本上避免循环迭代过程中的跨核心缓存同步。示例修改参考：

#pragma omp parallel shared(a, len, th) num_threads(no) if (len > 1000)
{
    int tid = omp_get_thread_num();
    int local_counter = 0; // 栈上私有变量，无共享、无伪共享问题
#pragma omp for 
    for (int la = 0; la < len; ++la)
    {
        local_counter++;
        a[la] = la * 2 + 1; 
    }
    th[tid] = local_counter; // 仅单次写入共享变量
}

• 调整测试负载规模：把数组长度提升到1e8以上（总计算量达到秒级），此时并行的固定开销占比会降到可忽略的程度，才能观察到正常的多线程加速比。针对当前纯连续写的测试用例，可以把循环操作改成带计算、带读访问的逻辑（比如对a数组的元素做浮点累加、逐元素计算后写回），避免单线程直接打满内存带宽导致的多线程无收益问题。
• 修正测试流程：
  • 每个测试用例连续运行5次以上，剔除最高、最低值后取平均耗时
  • 把动态内存分配的操作挪到计时逻辑外面，避免首次缺页中断影响测量结果
  • 测试前提前给数组做全量写预热，消除第一次访问的缺页开销
• 针对VS2015的OpenMP环境，可以手动指定循环调度方式：在#pragma omp for后增加schedule(static)参数，跳过运行时的调度策略判断，减少并行块的固定开销。

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