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

你真正要问的是“用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不允许混淆的事实，除非使用了EQUIVALENCE语句。任何有别名的代码都不是有效的Fortran，但是它是由程序员而不是编译器来检测这些错误的。因此，Fortran编译器忽略了可能的内存指针别名，并允许它们生成更有效的代码。看一下C语言中的这个小例子:

void transform (float *output, float const * input, float const * matrix, int *n)
{
    int i;
    for (i=0; i<*n; i++)
    {
        float x = input[i*2+0];
        float y = input[i*2+1];
        output[i*2+0] = matrix[0] * x + matrix[1] * y;
        output[i*2+1] = matrix[2] * x + matrix[3] * y;
    }
}

这个函数在优化后会比Fortran函数运行得慢。为什么如此?如果你在输出数组中写入值，你可能会改变矩阵的值。毕竟，指针可以重叠并指向相同的内存块(包括int指针!)C编译器被迫从内存中重新加载所有计算的四个矩阵值。

在Fortran中，编译器只加载一次矩阵值，并将它们存储在寄存器中。它可以这样做是因为Fortran编译器假定指针/数组在内存中不重叠。

Fortunately, the restrict keyword and strict-aliasing have been introduced to the C99 standard to address this problem. It's well supported in most C++ compilers these days as well. The keyword allows you to give the compiler a hint that the programmer promises that a pointer does not alias with any other pointer. The strict-aliasing means that the programmer promises that pointers of different type will never overlap, for example a double* will not overlap with an int* (with the specific exception that char* and void* can overlap with anything).

If you use them you will get the same speed from C and Fortran. However, the ability to use the restrict keyword only with performance critical functions means that C (and C++) programs are much safer and easier to write. For example, consider the invalid Fortran code: CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30), which most Fortran compilers will happily compile without any warning but introduces a bug that only shows up on some compilers, on some hardware and with some optimization options.

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

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

The faster code is not really up to the language, is the compiler so you can see the ms-vb "compiler" that generates bloated, slower and redundant object code that is tied together inside an ".exe", but powerBasic generates too way better code. Object code made by a C and C++ compilers is generated in some phases (at least 2) but by design most Fortran compilers have at least 5 phases including high-level optimizations so by design Fortran will always have the capability to generate highly optimized code. So at the end is the compiler not the language you should ask for, the best compiler i know is the Intel Fortran Compiler because you can get it on LINUX and Windows and you can use VS as the IDE, if you're looking for a cheap tigh compiler you can always relay on OpenWatcom.

更多信息: http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html

There is another item where Fortran is different than C - and potentially faster. Fortran has better optimization rules than C. In Fortran, the evaluation order of an expressions is not defined, which allows the compiler to optimize it - if one wants to force a certain order, one has to use parentheses. In C the order is much stricter, but with "-fast" options, they are more relaxed and "(...)" are also ignored. I think Fortran has a way which lies nicely in the middle. (Well, IEEE makes the live more difficult as certain evaluation-order changes require that no overflows occur, which either has to be ignored or hampers the evaluation).

另一个更聪明的规则领域是复数。这不仅是因为直到c99才有了它们，而且Fortran中管理它们的规则更好;由于gfortran的Fortran库部分是用C编写的，但实现了Fortran语义，GCC获得了这个选项(也可以用于“普通”C程序):

-fcx-fortran-rules 复杂的乘法和除法遵循Fortran规则。范围缩减是作为复杂除法的一部分进行的，但是没有检查复杂乘法或除法的结果是否是“NaN + I*NaN”，试图在这种情况下挽救这种情况。

The alias rules mentioned above is another bonus and also - at least in principle - the whole-array operations, which if taken properly into account by the optimizer of the compiler, can lead faster code. On the contra side are that certain operation take more time, e.g. if one does an assignment to an allocatable array, there are lots of checks necessary (reallocate? [Fortran 2003 feature], has the array strides, etc.), which make the simple operation more complex behind the scenes - and thus slower, but makes the language more powerful. On the other hand, the array operations with flexible bounds and strides makes it easier to write code - and the compiler is usually better optimizing code than a user.

总的来说，我认为C和Fortran的速度差不多;选择应该更多的是你更喜欢哪种语言，或者是使用Fortran的全数组操作及其更好的可移植性更有用，还是使用C中更好的系统接口和图形用户界面库。

我将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编译器没有在不禁用更重要的优化的情况下观察括号的选项。