Fortran 的表现计算机语言基准游戏 http://shootout.alioth.debian.org/出奇的糟糕。今天的结果显示，Fortran 在两项四核测试中分别排名第 14 和第 11，在单核测试中排名第 7 和第 10。
现在，我知道基准测试从来都不是完美的，但 Fortran 仍然（现在是？）经常被认为是高性能计算的语言，而且看起来该基准测试中使用的问题类型应该对 Fortran 有利。在最近一篇关于计算物理的文章中，兰道（2008）写道： http://physics.orst.edu/~rubin/Papers/CP-2.pdf
然而，[Java] 并不那么高效或
也支持 HPC 和并行
处理方式与 FORTRAN 和 C 一样，
后两者高度发达
编译器和许多其他科学
可用的子程序库。
反过来，FORTRAN 仍然是
HPC 的主导语言，
FORTRAN 90/95 令人惊讶
优美、现代、有效的语言；
但可惜的是，几乎没有人教它
CS 部门和编译器可以
昂贵的。
难道仅仅是因为语言枪战所使用的编译器（Intel针对Linux的免费编译器）？
不，这不仅仅是因为编译器。
像这样的基准（程序之间的基准不同）很大程度上是程序员在编写任何给定程序时投入的工作量（和工作质量）。我怀疑 Fortran 在该特定指标上处于显着劣势——与 C 和 C++ 不同，想要尝试使基准程序变得更好的程序员数量非常少，并且与大多数其他东西不同，他们可能也不觉得他们有什么需要证明的。因此，人们没有动力花几天时间仔细研究生成的汇编代码并分析程序以使其运行得更快。
从获得的结果中可以清楚地看出这一点。一般来说，只要有足够的编程努力和一个像样的编译器，C、C++ 或 Fortran 都不会比汇编代码慢很多——当然在最坏的情况下不会超过 5-10%，除非是病态的情况。事实上，这里获得的实际结果比这更加不同，这表明我还没有花费“足够的编程工作”。
当您允许程序集使用向量指令，但不允许 C/C++/Fortran 使用相应的编译器内部函数时，也存在例外情况 - 自动向量化甚至不是完美的近似值，而且可能永远不会。我不知道这些有多少可能适用于此。
类似地，一个例外是字符串处理之类的事情，您在很大程度上依赖于运行时库（其质量可能各不相同；Fortran 很少有快速字符串库能为编译器供应商赚钱的情况！），并且依赖于“字符串”的基本定义以及它在内存中的表示方式。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
