OpenMP并行循环后用户执行时间翻倍、墙钟时间无变化的问题排查

结合观测到的「并行版用户态执行时间是串行版2倍、墙钟时长基本持平」的现象，当前实现存在以下几类核心问题：

• 并行粒度严重不足，OpenMP固定开销远大于计算收益
  代码将#pragma omp parallel for reduction(+:rSum)标注在最外层nX循环上，OpenMP并行域本身存在固定的线程初始化、任务调度、域退出同步开销。如果网格交集的nX维度范围很小、单轮nX迭代对应的总计算量极轻（本质是遍历连续内存的低计算密度乘加操作），并行带来的固定开销会完全抵消计算收益，甚至因为多线程的额外调度消耗，直接推高总用户态时间。
• 默认静态调度适配性差，易出现线程空转与负载不均
  当前代码未给并行循环指定调度类型，默认采用静态块调度。如果nX维度的总迭代数少于可用线程数，会出现部分线程完全没有分配到实际计算任务，却仍然需要参与并行域创建、同步流程，白白消耗CPU时间。就算迭代数多于线程数，因为每个nX迭代下的nY、nZ遍历量是固定的，无动态调度适配空间，一旦块大小分配不均，会导致部分线程提前完成任务后空转等待同步，拉长总墙钟时间。
• 访存竞争与伪共享放大CPU时间损耗
  内层循环是连续遍历arLeft、arRight的内存地址做乘加，本身是缓存友好的顺序访问模式。但多线程并行时，如果静态分块边界刚好让相邻线程访问的内存地址落在同一个CPU缓存行（通常为64字节，对应8个double值），会触发频繁的缓存一致性失效，也就是伪共享问题——CPU需要反复在核心间同步缓存行状态，这些无效的缓存维护操作都会被计入用户态执行时间，进一步推高总耗时。
• 归约同步的额外开销被放大
  并行域上的reduction(+:rSum)操作，要求所有本地计算完成后，对各线程持有的rSum副本做同步归约。因为本身总计算量极小，这个同步过程的时间占比会被急剧放大：串行版本全程只需要维护一个rSum变量，无同步开销；并行版本需要多轮线程间的内存同步完成归约，这部分额外消耗就是用户态时间上涨的重要来源。

以上问题可直接解释观测到的现象：墙钟时长基本持平，是因为并行拆分后总实际计算量没有减少，额外的同步、调度开销把多线程节省的计算时间完全抵消；用户态时间翻倍，是因为多线程带来的线程调度、缓存一致性维护、同步归约的额外开销，全部叠加在原有计算耗时之上。

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