Fortran语言的表现上计算机语言基准游戏是出奇的差。 今天的结果提出的Fortran 14日和11日的两个四核试验，第7和第10的单内核。
现在，我知道基准是从不完美，但仍与Fortran是（是什么？）通常被认为是高性能计算的语言，它好像在这个基准测试中使用应该是Fortran语言的优势，问题的类型。 在计算物理的最近一篇文章中， 朗多（2008年）中写道：
然而，[爪哇]是效率不高或以及支持HPC和并行处理为是FORTRAN和C，具有高度发展的后两种可用的编译器和许多科学子程序库。 FORTRAN，反过来，仍然是HPC的主导语言，用FORTRAN 90/95是一个令人惊讶的漂亮的，现代化的，有效的语言; 但很可惜，它几乎不受任何CS部门教，和编译器可以是昂贵的。
难道只有通过语言枪战（英特尔对Linux的免费编译器）使用的编译器的原因？
不，这只是因为编译器不会。
什么基准这样的 - 该程序从基准不同的基准 - 主要是努力的量（和努力质量），程序员投入编写任何给定的程序。 我怀疑，Fortran语言是在特定的数据有显著的缺点 - 不象C和C ++，谁愿意想尝试他们的手在做的基准测试程序更好的程序员池是非常小，而不像大多数别的，他们可能不觉得自己有一些东西需要证明无论是。 因此，没有动机的人花了几天仔细查看生成的汇编代码和分析程序，使其走得更快。
这是从获得的结果相当明确。 在一般情况下，有足够的编程工作和体面的编译器，无论是C，C ++，Fortran语言也将会比汇编代码显著慢 - 肯定不会超过5-10％，在最坏的情况，除了病理情况下。 这里所获得的实际结果是比这更变的事实表明，我认为“足够的编程工作”尚未用完。
当然也有例外，当你让设备在使用向量指令，但不要让C / C ++ / Fortran语言使用相应的编译器内在 - 自动矢量甚至不是完美的近似值，可能永远不会。 我不知道有多少这些都可能适用于此。
同样，一个例外是东西像字符串处理，在那里你很大程度上依赖于运行时库（可能是质量参差不齐; Fortran语言很少，其中一个快速的字符串库会赚钱的编译器供应商的情况下！），并在一个“串”，以及如何在内存中的代表的基本定义。
一些随机的想法：
FORTRAN用来做非常好，因为它更容易识别哪些做了一些优化编译器更容易循环不变。 自那以后
restricted和const int const *p在c和inline于C ++）。 不知道FORTRAN 90或95，如果这些都跟上我不能说。 I've looked at these tests. It's not like the compiler is wrong or something. In most tests Fortran is comparable to C++ except some where it gets beaten by a factor of 10. These tests just reflect what one should know from the beggining - that Fortran is simply NOT an all-around interoperable programming language - it is suited for efficient computation, has good list operations & stuff but for example IO sucks unless you are doing it with specific Fortran-like methods - like e.g. 'unformatted' IO.
Let me give you an example - the 'reverse-complement' program that is supposed to read a large (of order of 10^8 B) file from stdin line-by-line, does something with it & prints the resulting large file to stdout. The pretty straighforward Fortran program is about 10 times slower on a single core (~10s) than a HEAVILY optimized C++ (~1s). When you try to play with the program, you'll see that only simple formatted read & write take more than 8 seconds. In a Fortran way, if you care for efficiency, you'd just write an unformatted structure to a file & read it back in no time (which is totally non-portable & stuff but who cares anyway - an efficient code is supposed to be fast & optimized for a specific machine, not able to run everywhere).
So the short answer is - don't worry, just do your job - and if you want to write a super-efficient operating system, than sorry - Fortran is just not the way for that kind of performance.
这个基准是愚蠢的。
例如，他们衡量CPU时间的整个程序运行 。 作为mcmint 陈述 （和它可能实际上是真的）的Fortran I / O很烂*。 但谁在乎？ 在现实世界中的任务，几秒钟比一个读法输入做小时/天/月计算，最后写的秒输出。 这就是为什么在大多数基准I / O操作被排除在时间测量（如果你当然本身不基准I / O）。
Norber维纳在他的书神与魔像，公司写道：
渲染对人这是男人的就对计算机这是计算机的东西的事情。
在我看来，这一原则的使用，同时在任何编程语言实现算法是指：
写为可读和简单的代码，你可以让编译器做了优化。
尤其是在现实世界（巨大）的应用非常重要。 （在许多基准，以便大量使用），即使他们可能会提高效率，在一定程度上（5％，也许10％）搞鬼不为现实世界的项目。
/ * C / C ++使用流I / O，但Fortran的传统使用基于记录的I / O。 进一步阅读 。 无论如何，我/在基准Ø是如此令人惊讶。 标准输入/输出重定向的使用也可能是问题的根源。 为什么不直接使用的读/写文件的语言和标准库提供的能力吗？ 这再一次woud更加真实世界的情况。
我想说的是，即使基准不带来了最好的结果FORTRAN，这种语言仍然会使用并在相当长的时间。 使用的原因并不只是性能，而且某种东西叫可编程的easyness。 很多人认为学会了在60年代和70年代使用它现在是太老了进入新的东西，他们知道如何使用FORTRAN不错。 我的意思是，有很多人为因素对要使用的语言。 程序员也很重要。
考虑到他们没有公布他们用于英特尔Fortran编译器的确切编译器选项，我在他们的基准一点信心。
我也此话既Intel的数学库，MKL，和AMD的数学库ACML，使用英特尔Fortran编译器。
编辑：
我没有找到编译选项，当你点击基准的名称。 由于优化级别似乎是合理的结果是令人惊讶的。 它可能回落到算法的效率。
