我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
当前回答
Fortran和C之间的速度差异更多的是编译器优化和特定编译器使用的底层数学库的函数。Fortran没有什么固有的特性可以使它比C更快。
不管怎样,一个优秀的程序员可以用任何语言编写Fortran。
其他回答
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速度更快有几个原因。然而,它们的重要性是如此无关紧要,或者可以通过任何方式解决,所以它不应该是重要的。现在使用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不允许混淆的事实,除非使用了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更简单。 到底哪个更快取决于算法,但无论如何,速度上没有很大的差别。这是我2015年在德国斯图加德高性能计算中心的Fortran研讨会上所学到的。我同时使用Fortran和C语言,我也有同样的观点。
解释:
C语言是用来编写操作系统的。因此,它拥有编写高性能代码所需的更多自由。一般来说,这是没有问题的,但是如果一个人不仔细编程,他很容易减慢代码的速度。
Fortran是为科学编程而设计的。因此,它支持编写语法方面的快速代码,因为这是Fortran的主要目的。与公众的看法相反,Fortran并不是一种过时的编程语言。它的最新标准是2010年,新的编译器定期发布,因为大多数高性能代码都是用Fortran编写的。Fortran进一步支持现代功能,如编译器指令(在C语言中)。
例子: 我们想给一个大的结构体作为函数的输入参数(fortran: suboutine)。在函数中,参数不会被改变。
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)和许多优秀的商业编译器。