我对我从英特尔编译的 Fortran 代码中得到的结果有疑问，该代码介于原始的两个 CPU 36 xeon 2690v2（我认为）线程机器和更新的两个 CPU 128 Xeon 6338 线程机器之间。 128 线程机器是 Rocky7 操作系统，但由于旧机器是 Redhat、CentOS 和一些我不记得的东西，我认为操作系统不是问题所在。数据从较旧机器上的 SATA SSD 从较新机器上的 M.2 驱动器运行，而新机器是 PCIe4 与旧 3。同样，我认为不会产生重大影响的东西，但也许我错了。该应用程序的 RAM 不重。我不能详细说明，提前抱歉，但我会澄清我能在哪里。
首先，我使用带有以下两个 ifort 调用的英特尔编译器：
ifort -O2 -qopenmp $srcnam -o $unam -c -w -fp-model precise -qopt-report-file:./parallel_opt_report.diag
这里有一些额外的代码
ifort -O2 -qopenmp $unam -w -Xlinker -L$bin -lifsubs64 -lifqsubs64 -limsl64 -lplot64 -ltcshp64 -lplot64 -lifsubs_no_opt64 -lifsubs64 -lifqsubs64 -llinpack64 -lYgl -fp-model precise
我使用的很多东西都是遗留代码，我一直在撬入较新的硬件或以其他方式调整以与较新的东西合作（我使用的很多 OG 代码已有数十年历史，F77 大部分调整为较新的95 个东西）。其中一个重大的性能提升是我们的工作从在单线程上运行到使用更新机器的 30 个线程。所以从逻辑上讲，当事情再次开始变慢时，我构建了另一台具有 128 个线程的机器，认为它会提供与以前相同的性能提升。做到了，太棒了。但我注意到，在我们大约 50 个结果中，有 3 个与 30 线程机器从同一数据集报告的结果不同。一个是微小的差异，另外两个是非常戏剧性的。诊断报告中没有任何内容表明脚本有问题，而且我得到的值也不是我过去所说的“异常”值。
我想知道 30 到 128 的变化是否对精度有足够大的影响，我开始在边缘情况下看到错误，以及是否有一些编译器魔法或 OMP 魔法可以轻松解决我看到的结果中的分歧。我怀疑的确切函数是一个巨大的点积，它可能只是野兽的本性，会分裂这么多线程，其中 30 低于某个阈值，而 128 高于该阈值。
代码中的 OMP 启动部分如下，如果有帮助的话：
CALL OMP_SET_NUM_THREADS(110)
!$OMP PARALLEL DO
!$OMP& DEFAULT(SHARED)
!$OMP& PRIVATE(LOOP VARIABLES)
!$OMP& SCHEDULE(STATIC)
!$OMP& REDUCTION(+:VARIABLES)
Code here using DDOT
!$OMP END PARALLEL DO
有什么想法或建议吗？对于编译器，我非常天真，所以如果我的代码/问题看起来像 ungabunga 说话，我深表歉意。
我希望 128 线程机器上的结果与使用相同数据的旧 30 线程机器上的结果相匹配。