Fortran的表现

Suu*_*aku 6 comparison performance benchmarking fortran

Fortran在计算机语言基准游戏方面的表现令人惊讶地糟糕.今天的结果将Fortran排在第14和第11位,在单核上进行了两次四核测试,第7次和第10次测试.

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

然而,[Java]不像FORTRAN和C那样有效或支持HPC和并行处理,后两者具有高度开发的编译器和更多科学的子程序库.反过来,FORTRAN仍然是HPC的主要语言,FORTRAN 90/95是一种令人惊讶的,现代的,有效的语言; 但是,任何CS部门都很难教授它,编译器也很昂贵.

是不是因为语言枪战使用的编译器(英特尔的Linux免费编译器)?

Bro*_*ses 6

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

像这样的基准测试——程序与基准测试不同——很大程度上取决于程序员为编写任何给定程序所付出的努力(和努力的质量)。我怀疑 Fortran 在该特定指标上处于显着劣势——与 C 和 C++ 不同,想要尝试使基准程序变得更好的程序员群体非常小,而且与大多数其他事物不同,他们很可能也不觉得他们有什么要证明的。因此,人们没有动力花几天时间研究生成的汇编代码并分析程序以使其运行得更快。

从获得的结果中可以很清楚地看出这一点。一般来说,如果有足够的编程工作和一个不错的编译器,C、C++ 和 Fortran 都不会比汇编代码慢得多——当然,最坏的情况下肯定不会超过 5-10%,除了病态的情况。此处获得的实际结果比这更多样化的事实向我表明尚未花费“足够的编程工作量”。

当您允许程序集使用向量指令,但不允许 C/C++/Fortran 使用相应的编译器内在函数时,存在例外情况——自动向量化甚至不是完美的近似值,而且可能永远不会。我不知道这些人在这里申请的可能性有多大。

类似地,在诸如字符串处理之类的事情中也有一个例外,在这种情况下,您严重依赖运行时库(其质量可能各不相同;Fortran 很少是一个快速字符串库可以为编译器供应商赚钱的情况!),以及“字符串”的基本定义以及它在内存中的表示方式。