使用现代标准和编译器，不!

Some of the folks here have suggested that FORTRAN is faster because the compiler doesn't need to worry about aliasing (and hence can make more assumptions during optimisation). However, this has been dealt with in C since the C99 (I think) standard with the inclusion of the restrict keyword. Which basically tells the compiler, that within a give scope, the pointer is not aliased. Furthermore C enables proper pointer arithmetic, where things like aliasing can be very useful in terms of performance and resource allocation. Although I think more recent version of FORTRAN enable the use of "proper" pointers.

对于现代实现，C通用优于FORTRAN(尽管它也非常快)。

http://benchmarksgame.alioth.debian.org/u64q/fortran.html

编辑:

一个公平的批评似乎是，基准测试可能是有偏见的。这里是另一个来源(相对于C)，将结果放在更多的上下文中:

http://julialang.org/benchmarks/

你可以看到C在大多数情况下优于Fortran(再次看到下面的批评也适用于这里);正如其他人所指出的，基准测试是一门不精确的科学，很容易偏袒一种语言而不是其他语言。但它确实说明了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 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不允许混淆的事实，除非使用了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编译器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编译器产生的较大销售额使得这种情况非常可行

是的，在1980年;在2008年?取决于

当我开始专业编程时，Fortran的速度优势正受到挑战。我记得我在Dr. Dobbs上读到过这篇文章，并把这篇文章告诉了年长的程序员——他们都笑了。

所以我对此有两种观点，理论上的和实际的。从理论上讲，今天的Fortran与C/ c++甚至任何允许汇编代码的语言相比，并没有内在的优势。在实践中，今天的Fortran仍然享有围绕优化数值代码而建立的历史和文化遗产的好处。

Up until and including Fortran 77, language design considerations had optimization as a main focus. Due to the state of compiler theory and technology, this often meant restricting features and capability in order to give the compiler the best shot at optimizing the code. A good analogy is to think of Fortran 77 as a professional race car that sacrifices features for speed. These days compilers have gotten better across all languages and features for programmer productivity are more valued. However, there are still places where the people are mainly concerned with speed in scientific computing; these people most likely have inherited code, training and culture from people who themselves were Fortran programmers.

当人们开始谈论代码优化时，会有很多问题，了解这一点的最好方法是潜伏在那些工作是快速编写数字代码的人身上。但是请记住，这种高度敏感的代码通常只占整个代码行的一小部分，而且非常专门:许多Fortran代码就像其他语言中的许多其他代码一样“低效”，优化甚至不应该是此类代码的主要关注点。

要开始了解Fortran的历史和文化，维基百科是一个很好的地方。Fortran维基百科的条目是一流的，我非常感谢那些花时间和精力使它对Fortran社区有价值的人。

(这个答案的缩短版本本可以在Nils开始的优秀帖子中发表评论，但我没有这样做的业力。实际上，如果不是因为这个帖子有实际的信息内容和分享，而不是激烈的争吵和语言偏见，我可能根本不会写任何东西，这是我对这个主题的主要经验。我不知所措，不得不分享这份爱。)