Fortran的表现 [英] Fortran's performance

问题描述

Fortran在计算机语言基准游戏上的表现令人惊讶。今天的结果让Fortran的第14和第11在两个四核测试，第7和第10在单核心。

Fortran's performances on Computer Language Benchmark Game are surprisingly bad. Today's result puts Fortran 14th and 11th on the two quad-core tests, 7th and 10th on the single cores.

现在，我知道基准从来不完美， Fortran是（是？）经常被认为是高性能计算的语言，似乎这种基准中使用的问题类型应该是Fortran的优势。在最近的一篇关于计算物理学的文章中， Landau（2008）写道：

Now, I know benchmarks are never perfect, but still, Fortran was (is?) often considered THE language for high performance computing and it seems like the type of problems used in this benchmark should be to Fortran's advantage. In an recent article on computational physics, Landau (2008) wrote:

但是，[Java]效率不高，或者
支持HPC和并行
处理是FORTRAN和C，
后两个具有高度开发的
编译器和许多更科学的
子程序库。
FORTRAN依然是HPC的
主导语言，
FORTRAN 90/95是令人惊讶的
好​​的，现代的和有效的语言;
但是唉，它几乎没有任何
CS部门教授，编译器可能是
昂贵。

However, [Java] is not as efficient or as well supported for HPC and parallel processing as are FORTRAN and C, the latter two having highly developed compilers and many more scientific subroutine libraries available. FORTRAN, in turn, is still the dominant language for HPC, with FORTRAN 90/95 being a surprisingly nice, modern, and effective language; but alas, it is hardly taught by any CS departments, and compilers can be expensive.

这只是因为语言输入（英特尔的Linux免费编译器）使用的编译器？

Is it only because of the compiler used by the language shootout (Intel's free compiler for Linux) ?

推荐答案

这不仅仅是因为编译器。

No, this isn't just because of the compiler.

这样的基准 - 程序与基准不同，基准 - 基本上是努力的量（和质量的努力），程序员写任何给定的程序。我怀疑Fortran在这个特定的度量上有一个显着的缺点 - 与C和C ++不同的是，想要尝试改进基准程序的程序员池非常小，与大多数其他的不同，他们可能不觉得他们有东西要证明。因此，没有人愿意花费几天时间浏览生成的汇编代码，并对程序进行分析以使其更快。

What benchmarks like this -- where the program differs from benchmark to benchmark -- is largely the amount of effort (and quality of effort) that the programmer put into writing any given program. I suspect that Fortran is at a significant disadvantage in that particular metric -- unlike C and C++, the pool of programmers who'd want to try their hand at making the benchmark program better is pretty small, and unlike most anything else, they likely don't feel like they have something to prove either. So, there's no motivation for someone to spend a few days poring over generated assembly code and profiling the program to make it go faster.

从结果中可以清楚地看出， 。一般来说，有足够的编程工作和一个体面的编译器，C，C ++和Fortran都不会显着慢于汇编代码 - 当然不超过5-10％，最坏的情况下，除了病理情况。事实上，这里获得的实际结果比它更加变化，这表明没有花费足够的编程工作。

This is fairly clear from the results that were obtained. In general, with sufficient programming effort and a decent compiler, neither C, C++, nor Fortran will be significantly slower than assembly code -- certainly not more than 5-10%, at worst, except for pathological cases. The fact that the actual results obtained here are more variant than that indicates to me that "sufficient programming effort" has not been expended.

当你允许程序集时有例外使用向量指令，但不允许C / C ++ / Fortran使用相应的编译器内在性 - 自动向量化甚至不是完美的近似，可能永远不会。

There are exceptions when you allow the assembly to use vector instructions, but don't allow the C/C++/Fortran to use corresponding compiler intrinsics -- automatic vectorization is not even a close approximation of perfect and probably never will be. I don't know how much those are likely to apply here.

同样，一个异常是在字符串处理，在那里你很大程度上依赖于运行时库可能具有不同的质量; Fortran很少是一个快速字符串库将为编译器供应商赚钱的情况），以及字符串的基本定义以及如何在内存中表示。

Similarly, an exception is in things like string handling, where you depend heavily on the runtime library (which may be of varying quality; Fortran is rarely a case where a fast string library will make money for the compiler vendor!), and on the basic definition of a "string" and how that's represented in memory.

这篇关于Fortran的表现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！