gfortran下OpenMP并行Fortran代码无加速反降速问题咨询

• 单迭代计算粒度过细，线程开销占比过高。单线程跑完8600次循环总耗时仅0.43s，平均单次迭代耗时仅50微秒级。MinGW64移植的libgomp运行时在Windows平台本身线程拉起、任务分发、上下文切换的固有开销就不低，2线程运行时这部分固定开销已经超过了并行拆分计算带来的收益，线程数越高开销占比越大，自然无法获得加速。
• *伪共享（False Sharing）*导致缓存频繁失效。你将数组访问改为output(:,i)适配Fortran列优先规则后，不同线程处理的相邻迭代对应的输出段在内存上完全连续，多个核心的写操作会落在同一个64字节CPU缓存行上，反复触发缓存一致性协议作废其他核心的缓存行，访存延迟暴涨，这也是改完内存布局后性能反而更差的核心原因——之前output(i,:)的写法下，不同迭代对应的输出段间隔为整个第二维度的长度，地址跨度大，伪共享问题反而更轻。
• OpenMP默认配置未做核绑定，线程漂移丢缓存。MinGW的libgomp在Windows下默认不会把线程固定到物理核心，线程运行过程中会在不同核心间调度切换，既增加上下文切换开销，也会导致核心上已经预热的L1/L2缓存数据完全失效。
• Windows默认线程栈空间不足。Windows下每个OpenMP线程默认栈大小仅1MB，如果something子例程内部定义了较大的局部数组，运行时会频繁触发栈边界探测、内存页申请拷贝，带来额外隐性开销。

• 手动指定调度块大小，拉平线程开销、缓解伪共享。不要使用OpenMP默认的迭代拆分规则，通过schedule(static, 块大小)参数让每个线程一次性领取上百个连续迭代处理，块大小可从128、256开始测试调整，既摊薄任务分发的调度开销，也能让每个线程持有的输出内存段足够大，跨过缓存行边界降低伪共享概率。修改后的并行指令写法如下：

!$omp parallel do default(shared) private(i) schedule(static, 256)
do i = 1, nF   
  call something(input1, input2(i), input3, input4, output1(:, i), output2(:, i), output3(:, i))   
end do 
!$omp end parallel do

• 强制线程绑定物理核心。运行程序前设置两个环境变量固定线程调度规则，避免线程漂移：

set OMP_PROC_BIND=TRUE
set OMP_PLACES=cores

• 增大线程栈空间。编译链接时增加参数-Wl,--stack=16777216，将每个OpenMP线程的栈大小调整为16MB，避免大局部数组带来的栈相关开销。
• 编译选项增加数组缓存行对齐。在现有编译参数中加上-falign-arrays=64，让全局/局部数组的起始地址自动对齐到64字节缓存行边界，进一步降低伪共享出现的概率。
• 若上述调整后性能仍不达预期，可替换编译器测试。MinGW64搭载的libgomp是从POSIX平台移植到Windows的版本，对Windows线程模型、NUMA架构的适配远不如Intel Fortran、MSVC自带的OpenMP运行时，同代码下换用原生Windows平台的编译器通常能获得30%以上的并行性能提升。

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