Fortran在Computer Language Benchmark Game上的表现令人惊讶地不好。今天的结果使Fortran在两个四核测试中排名第14和11，在单核上排名第7和10。
现在，我知道基准测试并非永远都是完美的，但仍然(经常是)Fortran被认为是高性能计算的语言，看来该基准测试中使用的问题类型应该对Fortran有利。在最近有关计算物理学的文章中，Landau (2008) wrote:
仅仅是因为语言大战使用了编译器(英特尔针对Linux的免费编译器)吗？
最佳答案
不，这不仅是因为编译器。
像这样的基准(程序因基准而异)在很大程度上是程序员在编写任何给定程序时付出的努力(和努力的质量)。我怀疑Fortran在该特定指标上处于显着劣势-与C和C++不同，想要尝试改善基准程序的程序员人数很少，而且与大多数其他事物不同，他们可能也不觉得他们有什么要证明的。因此，没有人会花几天的时间仔细研究生成的汇编代码并分析程序以使其运行更快。
从获得的结果中可以很明显地看出这一点。总的来说，只要有足够的编程力量和不错的编译器，C，C++和Fortran都不会比汇编代码慢得多-除非病理情况异常(exception)，最坏情况下肯定不会超过5-10％。此处获得的实际结果比实际情况多得多的事实向我表明，“足够的编程努力”尚未花费。
当您允许程序集使用向量指令，但不允许C/C++/Fortran使用相应的编译器内部函数时，会有一些异常(exception)情况-自动向量化甚至不是完美的近似值，也许永远不会。我不知道这些可能在这里应用多少。
同样，在诸如字符串处理之类的情况中，也有一个异常(exception)，在这种情况下，您很大程度上依赖于运行时库(其质量可能有所不同； Fortran很少会出现快速的字符串库能为编译器供应商赚钱的情况!)，并依赖于运行时库。 “字符串”的基本定义及其在内存中的表示方式。
关于performance - Fortran的表现，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1196814/