我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
当前回答
我将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编译器没有在不禁用更重要的优化的情况下观察括号的选项。
其他回答
我还没有听说过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%)
Fortran有更好的I/O例程,例如隐含的do工具提供了C标准库无法比拟的灵活性。
Fortran编译器直接处理更复杂的 涉及到语法,而且这样的语法不能轻易简化 参数传递形式,C不能有效地实现它。
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.
这两种语言具有相似的特性集。性能上的差异来自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编译器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编译器产生的较大销售额使得这种情况非常可行