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

你真正要问的是“用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编译器产生的较大销售额使得这种情况非常可行

I think the key point in favor of Fortran is that it is a language slightly more suited for expressing vector- and array-based math. The pointer analysis issue pointed out above is real in practice, since portable code cannot really assume that you can tell a compiler something. There is ALWAYS an advantage to expression computaitons in a manner closer to how the domain looks. C does not really have arrays at all, if you look closely, just something that kind of behaves like it. Fortran has real arrawys. Which makes it easier to compile for certain types of algorithms especially for parallel machines.

在运行时系统和调用约定等方面，C语言和现代的Fortran非常相似，很难看出有什么不同。注意，这里的C实际上是基础C: 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开始的优秀帖子中发表评论，但我没有这样做的业力。实际上，如果不是因为这个帖子有实际的信息内容和分享，而不是激烈的争吵和语言偏见，我可能根本不会写任何东西，这是我对这个主题的主要经验。我不知所措，不得不分享这份爱。)

我还没有听说过Fortan比C快得多，但是可以想象在某些情况下它会更快。关键不在于语言特征的存在，而在于那些(通常)不存在的特征。

一个例子是C指针。C指针几乎到处都在使用，但指针的问题是编译器通常无法判断它们是否指向同一个数组的不同部分。

例如，如果你写了一个strcpy例程，看起来像这样:

strcpy(char *d, const char* s)
{
  while(*d++ = *s++);
}

编译器必须在d和s可能是重叠数组的假设下工作。所以当数组重叠时，它不能执行会产生不同结果的优化。正如您所期望的，这在很大程度上限制了可以执行的优化类型。

[我应该注意到，C99有一个“restrict”关键字，显式地告诉编译器指针不重叠。还要注意，Fortran也有指针，语义不同于C语言，但指针不像C语言那样无处不在。

但是回到C与Fortran的问题上，可以想象，Fortran编译器能够执行一些对于(直接编写的)C程序可能无法实现的优化。所以我不会对这种说法感到太惊讶。不过，我确实希望性能差异不会太大。(~ 5 - 10%)

大多数帖子已经提出了令人信服的论点，所以我只是在另一个方面加上众所周知的2美分。

在处理能力方面，fortran更快或更慢是有其重要性的，但如果用fortran开发一些东西需要5倍多的时间，因为:

it lacks any good library for tasks different from pure number crunching it lack any decent tool for documentation and unit testing it's a language with very low expressivity, skyrocketing the number of lines of code. it has a very poor handling of strings it has an inane amount of issues among different compilers and architectures driving you crazy. it has a very poor IO strategy (READ/WRITE of sequential files. Yes, random access files exist but did you ever see them used?) it does not encourage good development practices, modularization. effective lack of a fully standard, fully compliant opensource compiler (both gfortran and g95 do not support everything) very poor interoperability with C (mangling: one underscore, two underscores, no underscore, in general one underscore but two if there's another underscore. and just let not delve into COMMON blocks...)

那么这个问题就无关紧要了。如果某样东西很慢，大多数时候你无法在给定的限制范围内改进它。如果你想要更快，改变算法。最后，使用电脑的时间很便宜。人类的时间不是。珍惜减少人类时间的选择。如果它增加了使用电脑的时间，无论如何它都是有成本效益的。

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.