Fortran的表现

Question

Fortran在Computer Language Benchmark Game上的表现非常糟糕。今天的结果让Fortran在单核上的第四和第十四次测试中排名第14和第11。

现在，我知道基准测试从来都不是完美的，但仍然，Fortran经常被认为是高性能计算的语言，看起来这个基准测试中使用的问题类型应该是Fortran的优势。在最近一篇关于计算物理学的文章中，Landau (2008) wrote:

  

但是，[Java]效率不高   同样支持HPC和并行   像FORTRAN和C一样处理   后两者高度发达   编译器和更多的科学   子程序库可用。   反过来，FORTRAN仍然是   HPC的主导语言   FORTRAN 90/95令人惊讶   美好，现代，有效的语言;   但唉，任何人都很难教   CS部门和编译器都可以   昂贵。

仅仅是因为语言枪战使用的编译器（英特尔的Linux免费编译器）？

Answer 1

不，这不仅仅是因为编译器。

这样的基准测试 - 程序在基准测试与基准测试之间的差异 - 主要是程序员编写任何给定程序所付出的努力量（以及努力程度）。我怀疑Fortran在这个特定的指标上处于一个显着的劣势 - 与C和C ++不同，那些希望尝试更好地制作基准程序的程序员群体非常小，而且与大多数其他指标不同，它们很可能不觉得他们有什么可以证明的。因此，没有动力让某人花几天时间仔细研究生成的汇编代码并对程序进行分析以使其更快。

从获得的结果中可以清楚地看出这一点。一般来说，通过充足的编程工作和合适的编译器，C，C ++和Fortran都不会比汇编代码慢得多 - 当然不会超过5-10％，除了病态情况。事实上，这里获得的实际结果比这更具变异性，这表明我没有花费“足够的编程工作量”。

当允许程序集使用向量指令时有例外，但不允许C / C ++ / Fortran使用相应的编译器内在函数 - 自动向量化甚至不是完美的近似，也可能永远不会。我不知道这些可能适用多少。

类似地，一个例外是像字符串处理这样的东西，你在很大程度上依赖于运行时库（可能质量不同; Fortran很少是快速字符串库为编译器供应商赚钱的情况！），以及“字符串”的基本定义以及它在内存中的表现方式。

Answer 2

一些随意的想法：

1. 编译器已经很多更复杂。特别是在c和c ++编译器中付出了巨大的努力。 fortran编译器跟不上吗？我想gfortran使用gcc和g ++的相同后端，但是intel编译器是什么？它曾经是好的，但它仍然是吗？
2. 有些语言有很多专门的关键字和语法来帮助编译器（c中为restricted和const int const *p，c ++中为inline。不知道fortran 90或95我不能说这些是否跟上了步伐。

Answer 3

我看过这些测试。它不像编译器是错的或什么的。在大多数测试中，Fortran可以与C ++相媲美，除了一些它被打了10倍。这些测试只反映了应该从开始时知道的东西 - Fortran不是一种全面的可互操作的编程语言 - 它适用于高效计算，具有良好的列表操作和但是，例如IO很糟糕，除非你使用特定的类Fortran方法进行操作 - 例如'unformatted'IO。

让我举个例子 - '反向补充'程序应该从stdin逐行读取一个大的（10 ^ 8 B的数量级）文件，用它做一些事情＆amp;将生成的大文件打印到stdout。与HEAVILY优化的C ++（~1s）相比，单核（~10s）上相当简单的Fortran程序慢约10倍。当您尝试使用该程序时，您将看到只有简单的格式化读取和放大器。写需要8秒以上。以Fortran的方式，如果你关心效率，你只需要在文件和文件中写一个未格式化的结构。马上读回来（这完全是非便携式的，但无论如何都要关心 - 一个高效的代码应该是快速的，针对特定的机器进行优化，不能在任何地方运行）。

所以简短的回答是 - 不要担心，只是做你的工作 - 如果你想写一个超高效的操作系统，而不是抱歉 - Fortran不是那种表现的方式。

Answer 4

这个基准是愚蠢的。

例如，他们测量the whole program to run的CPU时间。作为mcmint stated（它可能实际上是真的）Fortran I / O很糟糕*。但谁在乎？在实际任务中，读取输入几秒钟，而不是数小时/天/月的计算，最后写入秒的输出。这就是为什么在大多数基准测试中I / O操作被排除在时间测量之外（如果你当然不对I / O进行基准测试）。

Norber Wiener在他的书“上帝＆amp; amp; Golem，Inc。写道

  

将人类和计算机上的东西呈现给人类。

在我看来，在任何编程语言中实现算法时使用这个原则意味着：

  

尽可能编写可读且简单的代码，让编译器进行优化。

特别是它在现实世界（巨大的）应用程序中很重要。即使可能在一定程度上提高效率（5％，可能是10％），但是肮脏的技巧（在许多基准测试中使用得很多）并不适用于现实世界的项目。

/ * C / C ++使用流I / O，但Fortran传统上使用基于记录的I / O. Further reading。无论如何，基准测试中的I / O都是如此令人惊讶。 stdin / stdout重定向的使用也可能是问题的根源。为什么不简单地使用读/写语言或标准库提供的文件的能力？再一次，这将是更现实世界的情况。

Answer 5

我想说，即使基准测试没有为FORTRAN带来最好的结果，这种语言仍然会被使用很长一段时间。使用的原因不仅仅是性能，还有某种称为可编程性的简单性。在60年代和70年代学会使用它的很多人现在已经太老了，无法进入新的东西，他们知道如何使用FORTRAN。我的意思是，使用一种语言有很多人为因素。程序员也很重要。

Answer 6

考虑到他们没有发布他们用于英特尔Fortran编译器的确切编译器选项，我对他们的基准测试没有信心。

我还要说英特尔的数学库MKL和AMD的数学库ACML都使用英特尔Fortran编译器。

编辑：

当您点击基准测试名称时，我确实找到了编译选项。结果令人惊讶，因为优化级别似乎合理。这可能归结为算法的效率。