Intel Fortran 编译器在 Mac 上的结果不正确，但在 Linux 上则正常
我一直在使用 Fortran 中的快速多极代码。它对我来说是一个黑盒子，当我在 Mac 上编译它时，我一直感到有些奇怪。
我使用的是 11.1 版本的编译器，我有一台在 Snow Leopard 上运行 2.5 GHz Intel Core 2 Duo 的 MacBook Pro。
当我将优化标志设置为 -O0 时，代码运行良好，但当我使用 -O2 或 -O3 时，代码运行失败。奇怪的是，代码在 Linux 机器上运行良好，至少使用默认的 -O2 标志是这样。
有人对可能导致该问题的原因有任何想法吗？一定是矢量化的东西。
I have been working with a fast multipole code in Fortran. It is a black box to me, and I have been having some strangeness when compiling it on my mac.
I am using version 11.1 of the compiler, I've got a MacBook Pro running a 2.5 GHz Intel Core 2 Duo on Snow Leopard.
The code runs fine when I set the optimization flag to -O0, but fails when I use -O2 or -O3. What is bizarre is that the code runs fine on a Linux box, at least with the default -O2 flag.
Anyone have any ideas on what could be causing the issue? It must be something with vectorization.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
乍一看，在没有任何进一步信息的情况下，我就得出结论：你的程序不稳定；也就是说，当您调整优化（这对生成的代码有各种影响）时，您的程序会产生非常不同的结果（在某些情况下失败与非失败）。一些调整会对浮点运算的结果产生影响，这很容易导致长期运行的科学模拟的成功与失败之间的差异。
这是程序潜在“问题”的症状，我建议您不要依赖程序“成功”运行的结果，直到您更好地理解它 - 您需要打开黑匣子并看看里面有什么。
至少您应该测试程序对输入的微小变化的敏感性。
At first glance, and without any further information, I jump to the conclusion that your program is unstable; that is, your program produces very different results (failure vs non-failure in some cases) when you tweak the optimisation (which has all sorts of effects on the code that is generated). Some of the tweaks will have an impact on the results of floating-point arithmetic which can easily cause the difference between success and failure for long-running scientific simulations.
This is a symptom of an underlying 'issue' with the program and I would advise you not to rely on the results of 'successful' runs of the program until you understand it a lot better -- you need to prise open the black box and see what's inside.
At the very least you ought test the sensitivity of your program to small changes in inputs.
如前所述，最终结果可能对数值敏感，而放宽算术规则的优化会导致数值不稳定。或者优化可能会揭示程序中的错误。如果代码使用内部整数数组进行自己的内存管理（Fortran 90/95/2003 不再需要），则不同操作系统可能会出现问题。我会进一步调查...
我建议打开所有警告和检查选项。如果存在错误并且您很幸运，他们可能会揭露它或提供线索。至少尝试起来很容易。尝试这些选项：
-check all -traceback -warn all -fstack-protector
您还可以尝试“-assume protected_parens”，这将使 ifort 符合 Fortran 标准，并查看是否可以解决问题。
或者程序可能假设内存已预先分配给某个值。这与Linux和Mac有区别吗？我认为 ifort 有选项来控制这个。如果它是旧的 Fortran 77 代码，它可能会假设局部变量在过程调用中被保留，即使在声明中没有使用“save”。有一个编译器选项可以使所有局部变量的行为就像使用了“保存”一样——看看这是否会产生影响。
As already said, it is possible that the final result is numerically sensitive and optimization, which relaxes the arithmetic rules, is resulting in a numeric instability. Or optimization could be revealing a bug in the program. If the code is doing its own memory management (no longer necessary with Fortran 90/95/2003) with an internal array of ints, something could be going wrong different OS. I would investigate further...
I suggest turning on all warning and checking options. If there is a bug and you are lucky they might reveal it or give a clue. At least it is easy to try. Try these options:
-check all -traceback -warn all -fstack-protector
You could also try "-assume protect_parens", which will make ifort compliant with the Fortran standard, and see if that makes the problem go away.
Or maybe the program is assuming that memory is preallocated to some value. Is that a difference from Linux and Mac ?? I think that ifort has options to control this. If it is an old Fortran 77 code, it may assume that local variables are preserved across procedure calls, even without the use of "save" in the declarations. There is a compiler option to cause all local variables to act as if "save" were used -- see if that makes a difference.