Fortran比C更容易优化吗?

From time to time I read that Fortran is or can be faster then C for heavy calculations. Is that really true? I must admit that I hardly know Fortran, but the Fortran code I have seen so far did not show that the language has features that C doesn't have.

我不时地读到Fortran比C要快，或者可能比C要快。这是真的吗?我必须承认，我几乎不知道Fortran，但是到目前为止我看到的Fortran代码并没有显示出C语言具有的特性。

If it is true, please tell me why. Please don't tell me what languages or libs are good for number crunching, I don't intend to write an app or lib to do that, I'm just curious.

如果是真的，请告诉我为什么。请不要告诉我什么语言或lib适合数字运算，我不想写应用程序或lib来做这个，我只是好奇。

22 个解决方案

#1

The languages have similar feature-sets. The performance difference comes from the fact that Fortran says aliasing is not allowed, unless an EQUIVALENCE statement is used. Any code that has aliasing is not valid Fortran, but it is up to the programmer and not the compiler to detect these errors. Thus Fortran compilers ignore possible aliasing of memory pointers and allow them to generate more efficient code. Take a look at this little example in C:

这些语言都有相似的特性集。性能差异来自于这样一个事实:Fortran说除非使用等价语句，否则不允许别名。任何具有别名的代码都不是有效的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;
    }
}

This function would run slower than the Fortran counterpart after optimization. Why so? If you write values into the output array, you may change the values of matrix. After all, the pointers could overlap and point to the same chunk of memory (including the int pointer!). The C compiler is forced to reload the four matrix values from memory for all computations.

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

In Fortran the compiler can load the matrix values once and store them in registers. It can do so because the Fortran compiler assumes pointers/arrays do not overlap in memory.

在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).

幸运的是，为解决这个问题，C99标准引入了限制关键字和严格别名。现在，在大多数c++编译器中，它也得到了很好的支持。关键字允许你给编译器一个提示，程序员承诺一个指针不会与任何其他指针混在一起。严格别名表示程序员承诺不同类型的指针不会重叠，例如双*不会与int*重叠(具体的例外是char*和void*可以与任何东西重叠)。

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.

如果您使用它们，您将从C和Fortran获得相同的速度。但是，仅在性能关键函数中使用限定关键字的能力意味着C(和c++)程序更安全、更容易编写。例如，考虑无效的Fortran代码:调用转换(A(1,30)、A(2,31)、A(3,32)、30)，大多数Fortran编译器都乐于在没有任何警告的情况下编译它，但会引入一个只出现在某些编译器、某些硬件和一些优化选项上的bug。

#2

Yes, in 1980; in 2008? depends

When I started programming professionally the speed dominance of Fortran was just being challenged. I remember reading about it in Dr. Dobbs and telling the older programmers about the article--they laughed.

当我开始专业编程时，Fortran的速度优势正受到挑战。我记得在多布斯博士(Dr. Dobbs)上读到过这篇文章，还跟老程序员讲过这篇文章——他们笑了。

So I have two views about this, theoretical and practical. In theory Fortran today has no intrinsic advantage to C/C++ or even any language that allows assembly code. In practice Fortran today still enjoys the benefits of legacy of a history and culture built around optimization of numerical code.

对此我有两种观点，理论的和实践的。从理论上讲，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 77，包括Fortran 77，语言设计方面的考虑都以优化为主。由于编译器理论和技术的现状，这通常意味着限制特性和能力，以便给编译器优化代码的最佳机会。一个很好的类比是，把Fortran 77看作是一款为速度而牺牲特性的职业赛车。现在，编译器在所有语言和特性上都变得更好了，程序员的工作效率也得到了更大的重视。然而，仍然有一些地方人们主要关注科学计算的速度;这些人很可能从Fortran程序员那里继承了代码、培训和文化。

When one starts talking about optimization of code there are many issues and the best way to get a feel for this is to lurk where people are whose job it is to have fast numerical code. But keep in mind that such critically sensitive code is usually a small fraction of the overall lines of code and very specialized: A lot of Fortran code is just as "inefficient" as a lot of other code in other languages and optimization should not even be a primary concern of such code.

当人们开始讨论代码的优化时，会遇到很多问题，最好的方法是在人们工作的地方潜伏下来，让他们拥有快速的数字代码。但请记住,这种极度敏感的代码通常是整体的一小部分的代码行和非常专业的:许多Fortran代码一样“低效”在其他语言中很多其他代码和优化甚至不应该这样的代码的主要关注点。

A wonderful place to start in learning about the history and culture of Fortran is wikipedia. The Fortran Wikipedia entry is superb and I very much appreciate those who have taken the time and effort to make it of value for the Fortran community.

*是一个了解Fortran历史和文化的好地方。Fortran Wikipedia的条目非常棒，我非常感谢那些花时间和精力使它对Fortran社区有价值的人。

(A shortened version of this answer would have been a comment in the excellent thread started by Nils but I don't have the karma to do that. Actually, I probably wouldn't have written anything at all but for that this thread has actual information content and sharing as opposed to flame wars and language bigotry, which is my main experience with this subject. I was overwhelmed and had to share the love.)

(这个答案的简写本应该是由Nils开启的极好的帖子里的一条评论，但我可没这个本事。)实际上，我可能不会写任何东西，但这个线程有实际的信息内容和共享，而不是火焰战争和语言偏见，这是我在这个主题上的主要经验。我不知所措，不得不分享这份爱。

#3

To some extent Fortran has been designed keeping compiler optimization in mind. The language supports whole array operations where compilers can exploit parallelism (specially on multi-core processors). For example,

在某种程度上，Fortran的设计考虑到了编译器的优化。该语言支持整个数组操作，其中编译器可以利用并行性(特别是在多核处理器上)。例如,

Dense matrix multiplication is simply:

稠密矩阵乘法很简单:

matmul(a,b)

L2 norm of a vector x is:

向量x的L2范数为:

sqrt(sum(x**2))

Moreover statements such as FORALL, PURE & ELEMENTAL procedures etc. further help to optimize code. Even pointers in Fortran arent as flexible as C because of this simple reason.

此外，诸如FORALL、PURE & ELEMENTAL procedures等语句还有助于优化代码。甚至Fortran中的指针也没有C那么灵活，原因很简单。

The upcoming Fortran standard (2008) has co-arrays which allows you to easily write parallel code. G95 (open source) and compilers from CRAY already support it.

即将发布的Fortran标准(2008)具有子数组，允许您轻松编写并行代码。G95(开源)和CRAY的编译器已经支持它了。

So yes Fortran can be fast simply because compilers can optimize/parallelize it better than C/C++. But again like everything else in life there are good compilers and bad compilers.

因此，是的Fortran可以快速地实现，因为编译器可以优化/并行化它比C/ c++更好。但是，就像生活中的其他事物一样，有好的编译器和糟糕的编译器。

#4

It is funny that a lot of answers here from not knowing the languages. This is especially true for C/C++ programmers who have opened and old FORTRAN 77 code and discuss the weaknesses.

有趣的是，这里的许多答案都来自于对语言的不了解。对于已经打开并讨论了FORTRAN 77代码的C/ c++程序员尤其如此。

I suppose that the speed issue is mostly a question between C/C++ and Fortran. In a Huge code, it always depends on the programmer. There are some features of the language that Fortran outperforms and some features which C does. So, in 2011, no one can really say which one is faster.

我认为速度问题主要是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现在支持完整的OOP特性，并且完全向后兼容。我已经彻底地使用了Fortran 2003，我想说的是，使用它是令人愉快的。在某些方面，Fortran 2003仍然落后于c++，但是让我们看看它的用法。Fortran主要用于数值计算，由于速度的原因，没有人使用花哨的c++ OOP特性。在高性能计算中，c++几乎无处可去(看看MPI标准，您会发现c++已经被弃用了!)

Nowadays, you can simply do mixed language programming with Fortran and C/C++. There are even interfaces for GTK+ in Fortran. There are free compilers (gfortran, g95) and many excellent commercial ones.

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

#5

There are several reasons why Fortran could be faster. However the amount they matter is so inconsequential or can be worked around anyways, that it shouldn't matter. The main reason to use Fortran nowadays is maintaining or extending legacy applications.

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.

  函数的纯关键字和基本关键字。这些功能没有副作用。这允许在编译器知道用相同的值调用相同函数的特定情况下进行优化。注意:GCC实现“pure”作为语言的扩展。其他编译器也可以。模块间分析也可以执行这种优化，但这是困难的。

• 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

  处理数组而不是单个元素的标准函数集。诸如sin()、log()、sqrt()之类的东西都使用数组而不是标量。这使得优化程序更加容易。在大多数情况下，如果这些函数是内联的或内置的，那么自动向量化也会带来同样的好处

• 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, im; }; idiom used in C. It makes for faster development though as operators work on complex types in fortran.

  安装在内部的复杂类型。理论上，这可以允许编译器在某些情况下重新排序或删除某些指令，但您可能会看到结构{double re, im;};c语言中使用的习惯用法，虽然操作符在fortran中处理复杂的类型，但是可以加快开发速度。

#6

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.

我认为支持Fortran的关键是它是一种稍微更适合表示基于向量和数组的数学的语言。上面指出的指针分析问题在实践中是真实存在的，因为可移植代码不能真正假设您可以告诉编译器一些东西。用一种更接近领域外观的方式来表达computaitons总是有好处的。C实际上并没有数组，如果你仔细看的话，它的行为就是这样的。Fortran真正arrawys。这使得编译某些类型的算法变得更加容易，尤其是对于并行机器。

Deep down in things like run-time system and calling conventions, C and modern Fortran are sufficiently similar that it is hard to see what would make a difference. Note that C here is really base C: C++ is a totally different issue with very different performance characteristics.

在诸如运行时系统和调用约定之类的东西中，C和现代的Fortran非常相似，很难看出什么会有什么不同。注意，这里的C实际上是基础C: c++是一个完全不同的问题，具有非常不同的性能特征。

#7

There is no such thing as one language being faster than another, so the proper answer is no.

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

What you really have to ask is "is code compiled with Fortran compiler X faster than equivalent code compiled with C compiler Y?" The answer to that question of course depends on which two compilers you pick.

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

Another question one could ask would be along the lines of "Given the same amount of effort put into optimizing in their compilers, which compiler would produce faster code?" The answer to this would in fact be Fortran. Fortran compilers have certian advantages:

人们可能会问的另一个问题是，“如果在编译器中投入同样的精力进行优化，哪个编译器会生成更快的代码?”这个问题的答案实际上是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那时不得不与汇编程序竞争，当时一些人发誓永远不使用编译器，所以它是为速度而设计的。C的设计是灵活的。
• 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.
• Fortran的定位是数字运算。在这个域中，代码的速度永远不够快。所以一直有很多的压力来保持语言的效率。
• 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.
• 大多数关于编译器优化的研究都是由对加速Fortran数字处理代码感兴趣的人完成的，因此，与优化任何其他编译语言相比，优化Fortran代码是一个众所周知的问题。
• 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.
• Biggie: C鼓励更多的指针使用，而不是Fortran。这将大大增加C程序中任何数据项的潜在范围，这使得它们很难进行优化。注意，Ada在这个领域也比C要好得多，并且是一种比常见的Fortran77更为现代的OO语言。如果您想要一个OO langauge，它可以生成比C更快的代码，这是您的一个选项。
• Due again to its number-crunching niche, the customers of Fortran compilers tend to care more about optimization than the customers of C compilers.
• 由于它的数字处理小众，Fortran编译器的客户往往比C编译器的客户更关心优化。

However, there is nothing stopping someone from putting a ton of effort into their C compiler's optimization, and making it generate better code than their platform's Fortran compiler. In fact, the larger sales generated by C compilers makes this scenario quite feasible

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

#8

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).

Fortran与C语言还有另一个不同之处——而且可能更快。Fortran有比c更好的优化规则。在Fortran中，表达式的求值顺序没有定义，这允许编译器对其进行优化——如果要强制执行某个顺序，就必须使用圆括号。在C中，顺序要严格得多，但是在“-fast”选项中，它们更轻松，“(…)”也被忽略。我认为Fortran有一种很好的方法。(好吧，IEEE使实时操作变得更加困难，因为某些评估顺序的变化要求不出现溢出，这要么必须被忽略，要么妨碍评估)。

Another area of smarter rules are complex numbers. Not only that it took until C 99 that C had them, also the rules govern them is better in Fortran; since the Fortran library of gfortran is partially written in C but implements the Fortran semantics, GCC gained the option (which can also be used with "normal" C programs):

另一个更聪明的规则是复数。不仅如此，直到C 99 C有了它们，规则管理它们在Fortran中更好;由于gfortran的Fortran库部分是用C语言编写的，但是实现了Fortran语义，GCC获得了选项(也可以与“普通”C程序一起使用):

-fcx-fortran-rules Complex multiplication and division follow Fortran rules. Range reduction is done as part of complex division, but there is no checking whether the result of a complex multiplication or division is "NaN + I*NaN", with an attempt to rescue the situation in that case.

-fcx- Fortran规则复乘法和除法遵循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.

上面提到的别名规则是另一个好处，而且(至少在原则上)是整个数组操作，如果编译器的优化器适当地考虑到这些操作，可以导致更快的代码。相反地，某些操作需要花费更多的时间，例如，如果对一个可分配的数组进行赋值，则需要进行许多检查(重新分配?[Fortran 2003特性]，具有数组步进等)，这使得简单的操作在幕后变得更加复杂——因此速度更慢，但使语言更强大。另一方面，具有灵活边界和跨步的数组操作使编写代码变得更容易——而且编译器通常比用户更好地优化代码。

In total, I think both C and Fortran are about equally fast; the choice should be more which language does one like more or whether using the whole-array operations of Fortran and its better portability are more useful -- or the better interfacing to system and graphical-user-interface libraries in C.

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

#9

There is nothing about the languages Fortran and C which makes one faster than the other for specific purposes. There are things about specific compilers for each of these languages which make some favorable for certain tasks more than others.

对于语言Fortran和C语言来说，没有什么比其他语言更适合于特定的目的了。每种语言都有特定的编译器，这使得某些特定的编译器比其他的更适合某些任务。

For many years, Fortran compilers existed which could do black magic to your numeric routines, making many important computations insanely fast. The contemporary C compilers couldn't do it as well. As a result, a number of great libraries of code grew in Fortran. If you want to use these well tested, mature, wonderful libraries, you break out the Fortran compiler.

多年来，Fortran编译器一直存在，它可以对数字例程进行黑魔法，使许多重要的计算变得异常快速。当代的C编译器也做不到这一点。因此，在Fortran语言中增加了许多很棒的代码库。如果您想要使用这些经过测试的、成熟的、出色的库，您就可以打开Fortran编译器。

My informal observations show that these days people code their heavy computational stuff in any old language, and if it takes a while they find time on some cheap compute cluster. Moore's Law makes fools of us all.

我的非正式观察显示，如今人们用任何一种旧语言编写繁重的计算代码，如果花点时间在一些廉价的计算集群上的话。摩尔定律愚弄了我们所有人。

#10

I compare speed of Fortran, C, and C++ with the classic Levine-Callahan-Dongarra benchmark from netlib. The multiple language version, with OpenMP, is http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors The C is uglier, as it began with automatic translation, plus insertion of restrict and pragmas for certain compilers. C++ is just C with STL templates where applicable. To my view, the STL is a mixed bag as to whether it improves maintainability.

我将Fortran、C和c++的速度与netlib的经典Levine-Callahan-Dongarra基准进行了比较。使用OpenMP的多语言版本是http://sites.google.com/site/tprincesite/levine- callahan-dongarra-dongarhan -dongarra-vectors，因为它从自动翻译开始，并为某些编译器插入限制和实用程序。c++仅仅是带有STL模板的C。在我看来，STL是一个混合包，它是否提高了可维护性。

There is only minimal exercise of automatic function in-lining to see to what extent it improves optimization, since the examples are based on traditional Fortran practice where little reliance is place on in-lining.

只有很少的自动函数内联操作，才能看到它在多大程度上改进了优化，因为这些示例基于传统的Fortran实践，很少依赖内联。

The C/C++ compiler which has by far the most widespread usage lacks auto-vectorization, on which these benchmarks rely heavily.

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

Re the post which came just before this: there are a couple of examples where parentheses are used in Fortran to dictate the faster or more accurate order of evaluation. Known C compilers don't have options to observe the parentheses without disabling more important optimizations.

在此之前有一篇文章:在Fortran语言中，有几个例子使用圆括号来指示更快或更准确的计算顺序。已知的C编译器不能在不禁用更重要的优化的情况下观察圆括号。

#11

I was doing some extensive mathematics with FORTRAN and C for a couple of years. From my own experience I can tell that FORTRAN is sometimes really better than C but not for its speed (one can make C perform as fast as FORTRAN by using appropriate coding style) but rather because of very well optimized libraries like LAPACK, and because of great parallelization. On my opinion, FORTRAN is really awkward to work with, and its advantages are not good enough to cancel that drawback, so now I am using C+GSL to do calculations.

几年来，我一直在用FORTRAN和C进行一些广泛的数学研究。根据我自己的经验，我可以看出FORTRAN有时确实比C好，但不是因为它的速度(通过使用适当的编码风格，可以使C的性能与FORTRAN一样快)，而是因为像LAPACK这样经过了很好的优化的库，而且因为有很大的并行性。在我看来，FORTRAN非常笨拙，它的优点不足以抵消这个缺点，所以我现在使用c++ GSL进行计算。

#12

I'm a hobbyist programmer and i'm "average" at both language. I find it easier to write fast Fortran code than C (or C++) code. Both Fortran and C are "historic" languages (by today standard), are heavily used, and have well supported free and commercial compiler.

我是一个业余程序员，两种语言我都是“一般”。我发现写快速Fortran代码要比写C(或c++)代码容易。Fortran和C都是“历史”语言(到今天的标准)，被大量使用，并且很好地支持免费和商业编译器。

I don't know if it's an historic fact but Fortran feel like it's built to be paralleled/distributed/vectorized/whatever-many-cores-ized. And today it's pretty much the "standard metric" when we're talking about speed : "does it scale ?"

我不知道这是否是一个历史性的事实，但是Fortran觉得它是被并行化/分布式/向量化/各种各样的核心化的。如今，当我们谈论速度时，它几乎就是“标准度量”:“它能伸缩吗?”

For pure cpu crunching i love Fortran. For anything IO related i find it easier to work with C. (it's difficult in both case anyway).

对于纯粹的cpu运算，我喜欢Fortran。对于任何与IO相关的事情，我发现与c一起工作更容易(无论如何，这在两种情况下都很困难)。

Now of course, for parallel math intensive code you probably want to use your GPU. Both C and Fortran have a lot of more or less well integrated CUDA/OpenCL interface (and now OpenACC).

当然，对于并行数学密集型代码，您可能需要使用GPU。C和Fortran都有很多或多或少的完整的CUDA/OpenCL接口(现在是OpenACC)。

My moderately objective answer is : If you know both language equally well/poorly then i think Fortran is faster because i find it easier to write parallel/distributed code in Fortran than C. (once you understood that you can write "freeform" fortran and not just strict F77 code)

我比较客观的回答是:如果你对两种语言都很了解，那么我认为Fortran更快，因为我发现用Fortran编写并行/分布式代码比c要容易(一旦你理解了可以编写“freeform”Fortran，而不仅仅是严格的F77代码)

Here is a 2nd answer for those willing to downvote me because they don't like the 1st answer : Both language have the features required to write high-performance code. So it's dependent of the algorithm you're implementing (cpu intensive ? io intensive ? memory intensive?), the hardware (single cpu ? multi-core ? distribute supercomputer ? GPGPU ? FPGA ?), your skill and ultimately the compiler itself. Both C and Fortran have awesome compiler. (i'm seriously amazed by how advanced Fortran compilers are but so are C compilers).

对于那些因为不喜欢第一个答案而拒绝我的人，这里有第二个答案:两种语言都具有编写高性能代码所需的特性。它依赖于你实现的算法(cpu密集型?io密集型?内存密集型?)，硬件(单cpu ?多核吗?分发的超级计算机吗?GPGPU吗?FPGA ?)，你的技能和最终的编译器本身。C和Fortran都有很棒的编译器。(我对Fortran编译器有多高级感到非常惊讶，C编译器也是如此)。

PS : i'm glad you specifically excluded libs because i have a great deal of bad stuff to say about Fortran GUI libs. :)

PS:我很高兴你特别排斥libs，因为我有很多关于Fortran GUI libs的坏消息要说。:)

#13

I haven't heard that Fortan is significantly faster than C, but it might be conceivable tht in certain cases it would be faster. And the key is not in the language features that are present, but in those that (usually) absent.

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

An example are C pointers. C pointers are used pretty much everywhere, but the problem with pointers is that the compiler usually can't tell if they're pointing to the different parts of the same array.

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

For example if you wrote a strcpy routine that looked like this:

例如，如果你写了一个像这样的strcpy例程:

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

The compiler has to work under the assumption that the d and s might be overlapping arrays. So it can't perform an optimization that would produce different results when the arrays overlap. As you'd expect, this considerably restricts the kind of optimizations that can be performed.

编译器必须在d和s可能是重叠数组的假设下工作。所以当数组重叠时，它不能进行优化，从而产生不同的结果。正如您所期望的那样，这极大地限制了可以执行的优化。

[I should note that C99 has a "restrict" keyword that explictly tells the compilers that the pointers don't overlap. Also note that the Fortran too has pointers, with semantics different from those of C, but the pointers aren't ubiquitous as in C.]

我应该注意到C99有一个“limit”关键字，它明确地告诉编译器指针没有重叠。还要注意Fortran也有指针，其语义与C不同，但是指针并不像C中那样普遍。

But coming back to the C vs. Fortran issue, it is conceivable that a Fortran compiler is able to perform some optimizations that might not be possible for a (straightforwardly written) C program. So I wouldn't be too surprised by the claim. However, I do expect that the performance difference wouldn't be all that much. [~5-10%]

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

#14

Any speed differences between Fortran and C will be more a function of compiler optimizations and the underlying math library used by the particular compiler. There is nothing intrinsic to Fortran that would make it faster than C.

Fortran和C之间的速度差异更多的是编译器优化的函数，以及特定编译器使用的底层数学库。Fortran并没有比C语言更快的特性。

Anyway, a good programmer can write Fortran in any language.

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

#15

Quick and simple: Both are equally fast, but Fortran is simpler. Whats really faster in the end depends on the algorithm, but there is considerable no speed difference anyway. This is what I learned in a Fortran workshop at high performance computing center Stuttgard, Germany in 2015. I work both with Fortran and C and share this opinion.

快速而简单:两者都同样快速，但是Fortran更简单。到底什么速度更快取决于算法，但无论如何都没有明显的速度差异。这是我2015年在德国斯图加德高性能计算中心的Fortran讲习班学到的。我和Fortran和C一起工作，并分享这个观点。

Explanation:

解释:

C was designed to write operating systems. Hence it has more freedom than needed to write high performance code. In general this is no problem, but if one does not programm carefully, one can easily slow the code down.

C是用来编写操作系统的。因此，它比编写高性能代码更*。一般来说，这不是问题，但是如果不小心编程，很容易降低代码速度。

Fortran was designed for scientific programming. For this reason, it supports writing fast code syntax-wise, as this is the main purpose of Fortran. In contrast to the public opinion, Fortran is not an outdated programming language. Its latest standard is 2010 and new compilers are published on a regular basis, as most high performance code is writen in Fortran. Fortran further supports modern features as compiler directives (in C pragmas).

Fortran语言是为科学编程而设计的。由于这个原因，它支持按照语法编写快速代码，因为这是Fortran的主要目的。与公众意见相反，Fortran并不是一种过时的编程语言。它的最新标准是2010年，新的编译器定期发布，因为大多数高性能代码都是用Fortran编写的。Fortran进一步支持现代特性作为编译器指令(在C语言中)。

Example: We want to give a large struct as an input argument to a function (fortran: subroutine). Within the function the argument is not altered.

示例:我们希望将一个大型结构体作为函数的输入参数(fortran:子例程)。在函数中，参数不会被改变。

C supports both, call by reference and call by value, which is a handy feature. In our case, the programmer might by accident use call by value. This slows down things considerably, as the struct needs to be copied in within memory first.

C同时支持引用调用和值调用，这是一个很方便的特性。在我们的例子中，程序员可能偶然地使用按值调用。这大大降低了速度，因为结构需要首先在内存中复制。

Fortran works with call by reference only, which forces the programmer to copy the struct by hand, if he really wants a call by value operation. In our case fortran will be automatically as fast as the C version with call by reference.

Fortran只处理按引用调用，这迫使程序员手工复制结构体，如果他真的希望按值操作调用的话。在我们的例子中，fortran会自动地和C版本一样快，通过引用调用。

#16

Generally FORTRAN is slower than C. C can use hardware level pointers allowing the programmer to hand-optimize. FORTRAN (in most cases) doesn't have access to hardware memory addressing hacks. (VAX FORTRAN is another story.) I've used FORTRAN on and off since the '70's. (Really.)

通常FORTRAN比C要慢，C可以使用硬件级指针，让程序员手工优化。FORTRAN(在大多数情况下)没有访问硬件内存寻址的技巧。(VAX FORTRAN是另一个故事。)从70年代开始我就断断续续地使用FORTRAN。(真的)。

However, starting in the 90's FORTRAN has evolved to include specific language constructs that can be optimized into inherently parallel algorithms that can really scream on a multi-core processor. For example, automatic Vectorizing allows multiple processors to handle each element in a vector of data concurrently. 16 processors -- 16 element vector -- processing takes 1/16th the time.

然而，从20世纪90年代开始，FORTRAN就已经进化到包含特定的语言结构，这些结构可以被优化为天生的并行算法，可以在多核处理器上发出真正的尖叫。例如，自动向量化允许多个处理器同时处理数据向量中的每个元素。16个处理器——16个元素向量——处理需要1/16的时间。

In C, you have to manage your own threads and design your algorithm carefully for multi-processing, and then use a bunch of API calls to make sure that the parallelism happens properly.

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

In FORTRAN, you only have to design your algorithm carefully for multi-processing. The compiler and run-time can handle the rest for you.

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

You can read a little about High Performance Fortran, but you find a lot of dead links. You're better off reading about Parallel Programming (like OpenMP.org) and how FORTRAN supports that.

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

#17

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.

更快的代码并不完全取决于语言，而是编译器，因此您可以看到ms-vb“编译器”生成臃肿、缓慢和冗余的对象代码，这些代码被绑定在一个“”中。但是powerBasic生成了更好的代码。由C和c++编译器生成的对象代码是在某些阶段(至少2个阶段)生成的，但是按照设计，大多数Fortran编译器至少有5个阶段，包括高级优化，所以通过design Fortran总是能够生成高度优化的代码。所以最后是编译器不是语言你应该问,我知道的最好的编译器是英特尔Fortran编译器,因为你可以得到它在LINUX和Windows和可以使用VS IDE,如果你正在寻找一个便宜的泰编译器你可以总是在OpenWatcom继电器。

More info about this: http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html

更多相关信息:http://ed- thelen.org/1401project/1401 - ibm - system - journal - fortran.html

#18

Most of the posts already present compelling arguments, so I will just add the proverbial 2 cents to a different aspect.

大多数文章已经提出了令人信服的论点，所以我将只在另一个方面增加2分。

Being fortran faster or slower in terms of processing power in the end can have its importance, but if it takes 5 times more time to develop something in Fortran because:

在处理能力方面，fortran更快或更慢最终会有它的重要性，但是如果它需要5倍多的时间来开发fortran语言，因为:

• 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?)
• 它有一个非常糟糕的IO策略(读/写顺序文件)。是的，随机存取文件存在，但是你见过他们被使用吗?
• 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)
• 有效缺乏一个完全标准的、完全兼容的opensource编译器(gfortran和g95都不支持所有内容)
• 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...)
• 与C的互操作性非常差(一个下划线，两个下划线，没有下划线，通常是一个下划线，如果有另一个下划线，则是两个下划线。让我们不要深入到公共区块……

Then the issue is irrelevant. If something is slow, most of the time you cannot improve it beyond a given limit. If you want something faster, change the algorithm. In the end, computer time is cheap. Human time is not. Value the choice that reduces human time. If it increases computer time, it's cost effective anyway.

那么这个问题就无关紧要了。如果某件事很慢，大多数时候你无法在给定的极限之外改进它。如果你想要更快，改变算法。最后，电脑时间很便宜。人类的时间不是。重视减少人类时间的选择。如果它增加了计算机时间，无论如何它都是有效的。

#19

Fortran has better I/O routines, e.g. the implied do facility gives flexibility that C's standard library can't match.

Fortran有更好的I/O例程，例如，隐含的do功能提供了C的标准库无法匹配的灵活性。

The Fortran compiler directly handles the more complex syntax involved, and as such syntax can't be easily reduced to argument passing form, C can't implement it efficiently.

Fortran编译器直接处理涉及的更复杂的语法，由于这种语法不能简单地简化为参数传递形式，所以C不能有效地实现它。

#20

Using modern standards and compiler, no!

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

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.

这里的一些人认为FORTRAN更快，因为编译器不需要担心别名(因此可以在优化过程中做出更多假设)。然而，自从C99(我认为)标准包含了limit关键字之后，这在C中已经得到了处理。它告诉编译器，在给定范围内，指针不被别名化。此外，C支持适当的指针算法，在性能和资源分配方面，别名之类的东西非常有用。虽然我认为最近版本的FORTRAN允许使用“适当的”指针。

For modern implementations C general outperforms FORTRAN (although it is very fast too).

对于现代的实现，C一般都比FORTRAN出色(尽管它也非常快)。

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

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

EDIT:

编辑:

A fair criticism of this seems to be that the benchmarking may be biased. Here is another source (relative to C) that puts result in more context:

对此的一个合理的批评似乎是，基准测试可能存在偏见。这里有另一个来源(相对于C)将结果放在更大的背景中:

http://julialang.org/benchmarks/

http://julialang.org/benchmarks/

You can see that C typically outperforms Fortran in most instances (again see criticisms below that apply here too); as others have stated, benchmarking is an inexact science that can be easily loaded to favour one language over others. But it does put in context how Fortran and C have similar performance.

您可以看到，在大多数情况下，C的性能通常都优于Fortran(同样可以看到下面的批评也适用于这里);正如其他人所指出的，基准测试是一门不精确的科学，很容易被用来偏爱一种语言而不是其他语言。但它确实说明了Fortran和C具有类似的性能。

#21

This is more than somewhat subjective, because it gets into the quality of compilers and such more than anything else. However, to more directly answer your question, speaking from a language/compiler standpoint there is nothing about Fortran over C that is going to make it inherently faster or better than C. If you are doing heavy math operations, it will come down to the quality of the compiler, the skill of the programmer in each language and the intrinsic math support libraries that support those operations to ultimately determine which is going to be faster for a given implementation.

这不仅仅是主观的，因为它涉及到编译器的质量等等。然而,为了更直接回答你的问题,从语言/编译器的角度来看没有什么关于Fortran / C,本质上是要让它更快或比C。如果你做沉重的数学操作,还是到编译器的质量,程序员的技能在每个语言和数学的内在支持库,支持这些操作最终确定哪些是更快的对于一个给定的实现。

EDIT: Other people such as @Nils have raised the good point about the difference in the use of pointers in C and the possibility for aliasing that perhaps makes the most naive implementations slower in C. However, there are ways to deal with that in C99, via compiler optimization flags and/or in how the C is actually written. This is well covered in @Nils answer and the subsequent comments that follow on his answer.

编辑:@Nils等人提出了好一点的差异中指针的使用C和混淆的可能性,也许最天真的实现慢使C。然而,有办法应对,在C99,通过编译器优化旗帜和/或C是如何写的。这在@Nils的回答中得到了很好的介绍，随后他的回答中也有相关的评论。

#22

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传统上并没有设置诸如-fp这样的选项(ifort要求使用ieee_算法中的一些特性，这是f2003标准的一部分)。Intel c++也没有将-fp:严格设置为默认值，但是这对于ERRNO处理是必需的，例如，其他c++编译器不能方便地关闭ERRNO或获得诸如simd约简之类的优化。gcc和g++已经要求我设置Makefile，以避免使用危险的组合-O3 -ffast-math -math -fopenmp -march=native。除了这些问题之外，有关相对性能的问题变得更加挑剔，并且依赖于有关编译器和选项的选择的本地规则。