Fortran 在计算机语言基准游戏中的表现出奇的差。今天的结果将 Fortran 放在两个四核测试中的第 14 位和第 11 位，单核测试中的第 7 位和第 10 位。
现在，我知道基准测试从来都不是完美的，但是，Fortran 仍然（是？）经常被认为是高性能计算的语言，而且看起来这个基准测试中使用的问题类型应该是 Fortran 的优势。在最近一篇关于计算物理学的文章中，Landau (2008) 写道：
然而，[Java] 在 HPC 和并行处理方面不如 FORTRAN 和 C 那样高效或得到很好的支持，后两者具有高度开发的编译器和更多可用的科学子例程库。反过来，FORTRAN 仍然是 HPC 的主要语言，FORTRAN 90/95 是一种令人惊讶的好、现代和有效的语言；但是很遗憾，任何 CS 部门都几乎没有教授它，而且编译器可能很昂贵。
仅仅是因为语言大战使用的编译器（英特尔为 Linux 提供的免费编译器）吗？
不，这不仅仅是因为编译器。
像这样的基准测试——程序因基准测试而异——很大程度上是程序员在编写任何给定程序时所付出的努力（和努力的质量）。我怀疑 Fortran 在该特定指标上处于显着劣势——与 C 和 C++ 不同，想要尝试使基准程序更好的程序员群体非常少，而且与大多数其他东西不同，他们可能也不觉得他们有什么要证明的。因此，没有人愿意花几天时间仔细研究生成的汇编代码并分析程序以使其运行得更快。
从获得的结果中可以清楚地看到这一点。一般来说，只要有足够的编程工作量和体面的编译器，C、C++ 和 Fortran 都不会比汇编代码慢得多——当然，在最坏的情况下不会超过 5-10%，除了病态的情况。此处获得的实际结果比这更多的事实表明，“足够的编程工作量”并没有被花费。
当您允许程序集使用向量指令但不允许 C/C++/Fortran 使用相应的编译器内在函数时存在例外情况——自动向量化甚至不是完美的近似值，而且可能永远不会。我不知道这些在这里有多少可能适用。
类似地，在字符串处理之类的情况下，您严重依赖运行时库（其质量可能参差不齐；Fortran 很少出现快速字符串库会为编译器供应商赚钱的情况！），以及“字符串”的基本定义以及它在内存中的表示方式。
这个基准是愚蠢的。
例如，他们测量整个程序运行的CPU 时间。正如 mcmint所说（实际上可能是真的）Fortran I/O 很糟糕*。但谁在乎？在现实世界的任务中，读取输入几秒钟，而不是计算几小时/几天/几个月，最后写入几秒钟的输出。这就是为什么在大多数基准测试中，I/O 操作被排除在时间测量之外（如果您当然不单独对 I/O 进行基准测试）。
Norber Wiener 在他的书 God & Golem, Inc. 中写道
把属于人的东西交给人，把属于计算机的东西交给电脑。
在我看来，在任何编程语言中实现算法时使用这一原则意味着：
尽可能编写可读且简单的代码，并让编译器进行优化。
特别是它在现实世界（巨大的）应用程序中很重要。肮脏的技巧（在许多基准测试中如此频繁地使用）即使它们可能会在一定程度上提高效率（5%，也许 10%），但不适用于现实世界的项目。
/* C/C++ 使用流 I/O，但 Fortran 传统上使用基于记录的 I/O。进一步阅读。无论如何，基准测试中的 I/O 是如此令人惊讶。stdin/stdout 重定向的使用也可能是问题的根源。为什么不简单地使用语言或标准库提供的读/写文件的能力呢？再一次，这将是更真实的情况。
我看过这些测试。这不像编译器是错误的或什么的。在大多数测试中，Fortran 可与 C++ 相媲美，但在某些测试中它被击败了 10 倍。这些测试只是反映了人们从一开始就应该知道的事情——Fortran 根本不是一种全能的可互操作的编程语言——它适用于高效计算，具有良好的列表操作和东西，但例如 IO 很糟糕，除非您使用特定的类似 Fortran 的方法来执行它 - 例如“未格式化”的 IO。
让我举个例子 - 'reverse-complement' 程序应该从标准输入中逐行读取一个大（10^8 B 的顺序）文件，用它做一些事情并将生成的大文件打印到标准输出。非常简单的 Fortran 程序在单核（~10 秒）上比经过高度优化的 C++（~1 秒）慢大约 10 倍。当您尝试使用该程序时，您会发现只有简单的格式化读写需要超过 8 秒。以 Fortran 的方式，如果您关心效率，您只需将未格式化的结构写入文件并立即将其读回（这完全是不可移植的东西，但无论如何都在乎 - 一个高效的代码应该是快速并针对特定机器进行了优化，无法在任何地方运行）。
所以简短的回答是——别担心，做你的工作——如果你想编写一个超高效的操作系统，很抱歉——Fortran 不是那种性能的方式。
一些随意的想法：
Fortran 过去做得很好，因为它更容易识别循环不变量，这使得编译器更容易进行一些优化。自那时候起
restrictedc ++ 中）。不知道 fortran 90 或 95 我不能说这些是否跟上了步伐。const int const *pinline我想说的是，即使基准测试没有为 FORTRAN 带来最好的结果，这种语言仍然会被使用很长时间。使用的原因不仅是性能，还包括某种称为易编程性的东西。许多在 60 年代和 70 年代学会使用它的人现在太老了，无法接触新事物，他们知道如何很好地使用 FORTRAN。我的意思是，要使用一种语言，有很多人为因素。程序员也很重要。
考虑到他们没有发布他们用于英特尔 Fortran 编译器的确切编译器选项，我对他们的基准测试没有信心。
我还要指出，英特尔的数学库 MKL 和 AMD 的数学库 ACML 都使用英特尔 Fortran 编译器。
编辑：
当您单击基准的名称时，我确实找到了编译选项。结果令人惊讶，因为优化级别似乎是合理的。这可能归结为算法的效率。