Fortran和C语言在特定目的上并没有哪一种语言比另一种更快。对于每种语言的特定编译器，有些编译器比其他编译器更适合某些任务。

多年来，Fortran编译器一直存在，它可以对你的数字例程施黑魔法，使许多重要的计算变得异常快速。当代的C编译器无法做到这一点。因此，在Fortran中出现了许多伟大的代码库。如果您想要使用这些经过良好测试的、成熟的、出色的库，就需要使用Fortran编译器。

我的非正式观察表明，如今人们用任何古老的语言来编码他们繁重的计算内容，如果这需要一段时间，他们就会在一些廉价的计算集群上找到时间。摩尔定律让我们所有人都成了傻瓜。

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

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

我将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 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.

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

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 77代码并讨论过其弱点的C/ c++程序员来说尤其如此。

我认为速度问题主要是C/ c++和Fortran之间的问题。在大型代码中，它总是取决于程序员。有一些语言特性是Fortran优于的，而一些特性是C优于的。所以，在2011年，没有人能真正说出哪一个更快。

About the language itself, Fortran nowadays supports Full OOP features and it is fully backward compatible. I have used the Fortran 2003 thoroughly and I would say it was just delightful to use it. In some aspects, Fortran 2003 is still behind C++ but let's look at the usage. Fortran is mostly used for Numerical Computation, and nobody uses fancy C++ OOP features because of speed reasons. In high performance computing, C++ has almost no place to go(have a look at the MPI standard and you'll see that C++ has been deprecated!).

现在，您可以简单地使用Fortran和C/ c++进行混合语言编程。Fortran中甚至有GTK+的接口。有免费的编译器(gfortran, g95)和许多优秀的商业编译器。