我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。

如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。


当前回答

我还没有听说过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%)

其他回答

我还没有听说过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%)

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

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

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 (which can, however, be called from C code as well, either linking against LAPACK directly or using the LAPACKE interface for C), 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.