我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
我不时地读到Fortran在繁重的计算中比C更快。这是真的吗?我必须承认我几乎不懂Fortran,但是到目前为止我看到的Fortran代码并没有显示出该语言具有C语言所不具备的特性。
如果是真的,请告诉我原因。请不要告诉我什么语言或库适合处理数字,我不打算写一个应用程序或库来做这个,我只是好奇。
当前回答
一般来说,FORTRAN比C慢。C可以使用硬件级指针,允许程序员手动优化。FORTRAN(在大多数情况下)不能访问硬件内存寻址黑客。(VAX FORTRAN是另一回事。)我从70年代开始断断续续地使用FORTRAN。(真的)。
然而,从90年代开始,FORTRAN已经发展到包括特定的语言结构,可以优化成内在的并行算法,真正可以在多核处理器上运行。例如,自动矢量化允许多个处理器同时处理数据向量中的每个元素。16个处理器——16个元素向量——处理需要1/16的时间。
在C语言中,您必须管理自己的线程并为多处理仔细设计算法,然后使用一堆API调用来确保并行性正确发生。
在FORTRAN中,您只需要为多处理仔细设计算法。编译器和运行时可以为您处理其余的工作。
您可以阅读一些关于高性能Fortran的内容,但是您会发现许多死链接。你最好阅读并行编程(比如OpenMP.org)以及FORTRAN如何支持并行编程。
其他回答
一般来说,FORTRAN比C慢。C可以使用硬件级指针,允许程序员手动优化。FORTRAN(在大多数情况下)不能访问硬件内存寻址黑客。(VAX FORTRAN是另一回事。)我从70年代开始断断续续地使用FORTRAN。(真的)。
然而,从90年代开始,FORTRAN已经发展到包括特定的语言结构,可以优化成内在的并行算法,真正可以在多核处理器上运行。例如,自动矢量化允许多个处理器同时处理数据向量中的每个元素。16个处理器——16个元素向量——处理需要1/16的时间。
在C语言中,您必须管理自己的线程并为多处理仔细设计算法,然后使用一堆API调用来确保并行性正确发生。
在FORTRAN中,您只需要为多处理仔细设计算法。编译器和运行时可以为您处理其余的工作。
您可以阅读一些关于高性能Fortran的内容,但是您会发现许多死链接。你最好阅读并行编程(比如OpenMP.org)以及FORTRAN如何支持并行编程。
在某种程度上,Fortran在设计时就考虑到了编译器优化。该语言支持整个数组操作,编译器可以利用并行性(特别是在多核处理器上)。例如,
密集矩阵乘法很简单:
matmul(a,b)
向量x的L2范数为:
sqrt(sum(x**2))
此外,FORALL、PURE和ELEMENTAL程序等语句进一步有助于优化代码。由于这个简单的原因,即使是Fortran中的指针也不如C语言灵活。
即将发布的Fortran标准(2008)具有协同数组,允许您轻松地编写并行代码。G95(开源)和来自CRAY的编译器已经支持它。
所以是的,Fortran可以很快,因为编译器可以比C/ c++更好地优化/并行化。但是就像生活中的其他事情一样,有好的编译器和坏的编译器。
简单快捷: 这两种语言同样快,但Fortran更简单。 到底哪个更快取决于算法,但无论如何,速度上没有很大的差别。这是我2015年在德国斯图加德高性能计算中心的Fortran研讨会上所学到的。我同时使用Fortran和C语言,我也有同样的观点。
解释:
C语言是用来编写操作系统的。因此,它拥有编写高性能代码所需的更多自由。一般来说,这是没有问题的,但是如果一个人不仔细编程,他很容易减慢代码的速度。
Fortran是为科学编程而设计的。因此,它支持编写语法方面的快速代码,因为这是Fortran的主要目的。与公众的看法相反,Fortran并不是一种过时的编程语言。它的最新标准是2010年,新的编译器定期发布,因为大多数高性能代码都是用Fortran编写的。Fortran进一步支持现代功能,如编译器指令(在C语言中)。
例子: 我们想给一个大的结构体作为函数的输入参数(fortran: suboutine)。在函数中,参数不会被改变。
C同时支持引用调用和值调用,这是一个非常方便的特性。在我们的例子中,程序员可能会意外地使用按值调用。这大大降低了速度,因为需要首先将结构体复制到内存中。
Fortran只使用引用调用,这迫使程序员手动复制结构,如果他真的想要按值调用操作。在我们的例子中,通过引用调用,fortran将自动和C版本一样快。
这两种语言具有相似的特性集。性能上的差异来自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 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.