没有一种语言比另一种语言更快，所以正确的答案是否定的。

你真正要问的是“用Fortran编译器X编译的代码是否比用C编译器Y编译的等效代码更快?”这个问题的答案当然取决于您选择哪两个编译器。

人们可能会问的另一个问题是“考虑到在他们的编译器中优化投入了相同的精力，哪个编译器会生成更快的代码?” 这个问题的答案实际上是Fortran。Fortran编译器有一些优势:

Fortran had to compete with Assembly back in the day when some vowed never to use compilers, so it was designed for speed. C was designed to be flexible. Fortran's niche has been number crunching. In this domain code is never fast enough. So there's always been a lot of pressure to keep the language efficient. Most of the research in compiler optimizations is done by people interested in speeding up Fortran number crunching code, so optimizing Fortran code is a much better known problem than optimizing any other compiled language, and new innovations show up in Fortran compilers first. Biggie: C encourages much more pointer use than Fortran. This drasticly increases the potential scope of any data item in a C program, which makes them far harder to optimize. Note that Ada is also way better than C in this realm, and is a much more modern OO Language than the commonly found Fortran77. If you want an OO langauge that can generate faster code than C, this is an option for you. Due again to its number-crunching niche, the customers of Fortran compilers tend to care more about optimization than the customers of C compilers.

然而，没有什么能阻止人们在C编译器的优化上投入大量精力，并使其生成比他们平台的Fortran编译器更好的代码。事实上，C编译器产生的较大销售额使得这种情况非常可行

Fortran速度更快有几个原因。然而，它们的重要性是如此无关紧要，或者可以通过任何方式解决，所以它不应该是重要的。现在使用Fortran的主要原因是维护或扩展遗留应用程序。

PURE and ELEMENTAL keywords on functions. These are functions that have no side effects. This allows optimizations in certain cases where the compiler knows the same function will be called with the same values. Note: GCC implements "pure" as an extension to the language. Other compilers may as well. Inter-module analysis can also perform this optimization but it is difficult. standard set of functions that deal with arrays, not individual elements. Stuff like sin(), log(), sqrt() take arrays instead of scalars. This makes it easier to optimize the routine. Auto-vectorization gives the same benefits in most cases if these functions are inline or builtins Builtin complex type. In theory this could allow the compiler to reorder or eliminate certain instructions in certain cases, but likely you'd see the same benefit with the struct { double re; double im; }; idiom used in C. It makes for faster development though as operators work on complex types in Fortran.

Fortran和C之间的速度差异更多的是编译器优化和特定编译器使用的底层数学库的函数。Fortran没有什么固有的特性可以使它比C更快。

不管怎样，一个优秀的程序员可以用任何语言编写Fortran。

Fortran traditionally doesn't set options such as -fp:strict (which ifort requires to enable some of the features in USE IEEE_arithmetic, a part of f2003 standard). Intel C++ also doesn't set -fp:strict as a default, but that is required for ERRNO handling, for example, and other C++ compilers don't make it convenient to turn off ERRNO or gain optimizations such as simd reduction. gcc and g++ have required me to set up Makefile to avoid using the dangerous combination -O3 -ffast-math -fopenmp -march=native. Other than these issues, this question about relative performance gets more nit-picky and dependent on local rules about choice of compilers and options.

我将Fortran、C和c++的速度与netlib中的经典Levine-Callahan-Dongarra基准进行了比较。使用OpenMP的多语言版本是 http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors C语言更丑陋，因为它一开始是自动翻译，加上某些编译器的限制和pragmas插入。 c++就是在适用的地方使用STL模板的C。在我看来，STL在是否能提高可维护性方面好坏参半。

为了了解自动函数内联在多大程度上改进了优化，只需要进行很少的练习，因为示例基于传统的Fortran实践，其中很少依赖内联。

到目前为止使用最广泛的C/ c++编译器缺乏自动向量化，而这些基准测试严重依赖于此。

关于这之前的帖子:在Fortran中使用括号来指示更快或更准确的求值顺序的例子有两个。已知的C编译器没有在不禁用更重要的优化的情况下观察括号的选项。

一般来说，FORTRAN比C慢。C可以使用硬件级指针，允许程序员手动优化。FORTRAN(在大多数情况下)不能访问硬件内存寻址黑客。(VAX FORTRAN是另一回事。)我从70年代开始断断续续地使用FORTRAN。(真的)。

然而，从90年代开始，FORTRAN已经发展到包括特定的语言结构，可以优化成内在的并行算法，真正可以在多核处理器上运行。例如，自动矢量化允许多个处理器同时处理数据向量中的每个元素。16个处理器——16个元素向量——处理需要1/16的时间。

在C语言中，您必须管理自己的线程并为多处理仔细设计算法，然后使用一堆API调用来确保并行性正确发生。

在FORTRAN中，您只需要为多处理仔细设计算法。编译器和运行时可以为您处理其余的工作。

您可以阅读一些关于高性能Fortran的内容，但是您会发现许多死链接。你最好阅读并行编程(比如OpenMP.org)以及FORTRAN如何支持并行编程。