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

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


当前回答

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.

其他回答

大多数帖子已经提出了令人信服的论点,所以我只是在另一个方面加上众所周知的2美分。

在处理能力方面,fortran更快或更慢是有其重要性的,但如果用fortran开发一些东西需要5倍多的时间,因为:

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

那么这个问题就无关紧要了。如果某样东西很慢,大多数时候你无法在给定的限制范围内改进它。如果你想要更快,改变算法。最后,使用电脑的时间很便宜。人类的时间不是。珍惜减少人类时间的选择。如果它增加了使用电脑的时间,无论如何它都是有成本效益的。

Fortran有更好的I/O例程,例如隐含的do工具提供了C标准库无法比拟的灵活性。

Fortran编译器直接处理更复杂的 涉及到语法,而且这样的语法不能轻易简化 参数传递形式,C不能有效地实现它。

Fortran和C语言在特定目的上并没有哪一种语言比另一种更快。对于每种语言的特定编译器,有些编译器比其他编译器更适合某些任务。

多年来,Fortran编译器一直存在,它可以对你的数字例程施黑魔法,使许多重要的计算变得异常快速。当代的C编译器无法做到这一点。因此,在Fortran中出现了许多伟大的代码库。如果您想要使用这些经过良好测试的、成熟的、出色的库,就需要使用Fortran编译器。

我的非正式观察表明,如今人们用任何古老的语言来编码他们繁重的计算内容,如果这需要一段时间,他们就会在一些廉价的计算集群上找到时间。摩尔定律让我们所有人都成了傻瓜。

我还没有听说过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比C慢。C可以使用硬件级指针,允许程序员手动优化。FORTRAN(在大多数情况下)不能访问硬件内存寻址黑客。(VAX FORTRAN是另一回事。)我从70年代开始断断续续地使用FORTRAN。(真的)。

然而,从90年代开始,FORTRAN已经发展到包括特定的语言结构,可以优化成内在的并行算法,真正可以在多核处理器上运行。例如,自动矢量化允许多个处理器同时处理数据向量中的每个元素。16个处理器——16个元素向量——处理需要1/16的时间。

在C语言中,您必须管理自己的线程并为多处理仔细设计算法,然后使用一堆API调用来确保并行性正确发生。

在FORTRAN中,您只需要为多处理仔细设计算法。编译器和运行时可以为您处理其余的工作。

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