FORTRAN 77程序比Fortran 90程序更快吗？

Question

FORTRAN 77程序比Fortran 90程序更快吗？

7

今天我在阅读一些非常流行的数值库的代码，比如QUADPACK（最后更新于1987年），这些代码是用FORTRAN 77编写的，我想知道除了需要大量工作之外，是否有任何理由不将这些库重写为Fortran 90，因为Fortran 90带来了很大的改进，包括自由格式源代码、更好的控制结构，因此GO TO可以被遗忘，向量化，接口等等。

是因为FORTRAN 77编译器产生更优化的代码，也许更适合并行执行？请注意，我甚至没有谈论Fortran 2003，例如，它“仅”有8年历史：我正在谈论Fortran 90，所以我认为它已经足够广泛，并且编译器已经准备好了。无论如何，我与工业界没有联系。

编辑：janneb是正确的：LAPACK实际上是用Fortran 90编写的。

- astrojuanlu

1

我认为这是因为对于已经被证明是有竞争力的东西来说，它会带来“大量的工作”。许多“更高级”的语言结构很好，但除非出现范式转变，否则它们很少有益于性能。也就是说，“使用新语法的代码”并不意味着“更好的编译器优化”，即使是F77（尽管我很痛苦地承认）也是一种“高级”语言。 - user166390

1

高效的Fortran代码应该以F77特性为核心，以实现高性能，大多数新特性通常会导致执行效率降低。 F90及以上版本主要有助于代码的可维护性和可扩展性。 - haraldkl

@haraldkl - 我猜你有一些强有力的证据来支持这样的说法？ - Rook

@pst，我明白这些库实际上是有效的，但我的意思不是为了提高性能而进行语法更改：我想知道是否没有进行这些更改是因为它们会导致性能变差。 - astrojuanlu

1

是的，这种策略有证据支持。我并不认为所有新功能都对性能产生负面影响，或者你根本不应该使用它们。只是在内核中，F77风格通常是生成高效代码的良好指南。（避免使用指针和目标属性，不使用细粒度派生数据类型，甚至有一段时间数组语法语句比显式do循环慢，尽管编译器似乎已经大大改进）。实际上，我正在大量使用F2003功能，我的观点只是在内核中，可能几乎没有好处。 - haraldkl

4个回答

6

没有必要花费大量的精力去改进本已运作良好的东西。需要注意的是，尽管Fortran 90引入了许多新功能，但它并没有改变语言。请记住，Fortran 90标准向后兼容FORTRAN 77。现代编译器能够像优化FORTRAN 77代码一样优化代码。在 Fortan 90 中引入了一些特性（例如指针）会影响效率，如果关心执行时间（例如在高性能计算中），应避免使用这些特性。因此，这并不会有什么区别。对于现代编译器而言，精心编写的FORTAN 77同样可以进行优化——就像没有糖衣的蛋糕。在Fortran 90及之后的版本中，糖衣看起来比味道更好——它对程序员很方便，但并不一定提高程序的效率。

- milancurcic

2

如果我没记错的话，实际上Fortran标准不是向后兼容的。Fortran 90废弃了FORTRAN 77的一些功能，而Fortran 95则删除了先前标准中已被弃用的一些功能。 - astrojuanlu

@Juanlu001 你说得对。我有些急于求成了。Fortran 90标准向后兼容Fortran 77（并且还添加了大多数语言功能）。 - milancurcic

2

IRO-bot，@Juanlu001 - 已经前进了，但并不多...要从Fortran标准中删除一个功能，必须经过几个阶段，到目前为止只有很少的一些被删除（非常不可移植和很少使用的功能）。然而，即使有这样的想法，大多数供应商仍然支持它们，无论标准如何。因此，是的，即使标准已经将它们驱逐出境，可以说Fortran编译器仍然具有非常好的向后兼容性。在F90中没有删除的功能，在F95中引入了一些，尽管我还没有看到任何不支持它们的编译器。 - Rook

实际上，这真的不是问题。如果我没记错，F2k没有将任何内容添加到过时列表中。 - Rook

5

Fortran 77程序之所以更快，一个主要原因是声明时定长数组比动态分配的数组（Fortran 90）更快。两者在内存中不处于同一位置，这涉及到Fortran的堆栈与堆内存管理。Fortran 90+拥有快速的“全部在块中”数组操作。gcc-fortran（gfortran）是我非常喜欢的编译器，对于大小为N的数组a，在没有任何编译选项的情况下，它可以提供相当快的运行速度。详见这里。请注意，保留HTML标记。

a = a + 1

比

快4倍。

do i = 1 , N
  a(i) = a(i) + 1
end do

这个测试是在我的机器上，使用gfortran编译器，没有优化选项，并且没有声称这是专业的基准测试。

分配“问题”（实际上不是问题而是特性）与架构、编译器或任何相关因素无关，而是与Fortran标准有关。

- max

4

动态分配内存会比静态分配更难被编译器优化，因为它们不够可预测。在Fortran标准中没有规定是将它们放在堆栈还是堆里，这很可能取决于系统、编译器和一次20面骰的结果。但这并不是一个真正的争论点，因为如果不需要可分配数组，我们肯定不想使用它们。 - milancurcic

但是在必须使用可分配数组的情况下，我们将不得不使用它们，不是吗？ :) 很好的答案Maximilien，感谢您指出这一点！我不是计算机科学专业的学生，所以对我来说这些事情并不容易。而且向量化也非常有用。 - astrojuanlu

但是在必须使用可分配数组的情况下，您无论如何都必须使用Fortran 90。因此，这不是比较F77与F90效率的相关论点。这就像比较苹果和橙子一样。 - milancurcic

@IRO-bot 原始问题是关于将F77库重写为F90+的兴趣。我想我们不仅仅讨论风格（自由格式与固定格式）。如果您只是删除无用的空格并将“C”转换为“!”，那么... 77to90毫无意义。如果您的目标是真正使用F90+及其功能，则可以考虑我的答案。顺便说一下，您可能无法将苹果变成橙子。比较更多是在苹果和更大的苹果之间。 - max

1

@MaximilienLevesque 我明白你的意思。我认为问题的范围是特定于在不改变应用程序和语义的情况下重写F77到F90。因此，像数组操作和新的流程控制结构这样的功能对比很重要，但是动态分配在我看来并不是很重要。请注意，我同意你的答案（+1），但对我来说仍然是苹果和橙子的区别 :)。 - milancurcic

#pragma openmp，mpi，mpich等，在不需要进行内存管理的情况下，使用do i = 1，N a（i）= a（i）+1 end do。F77仍然会对F90代码进行蛮力数值计算的破坏，这也是F77的设计初衷。F77不是Matlab或Python。它的作用是处理大量矩阵数据，给我一些特征向量、奇异值分解或分解结果。 - μολὼν.λαβέ

1

讨论F77程序与使用新语法重写的等效F90程序哪个更快或更慢是有争议的，但现在先不考虑这个问题。

然而应该考虑的是，没有人真正关心速度本身。人们只关心在相关情况下和对业务有益的执行速度（我相信有一个更好的术语，但现在想不起来了...也许是“成本效益”）。

由于这两个（相当流行的库）仍然使用F77，很明显普遍意见认为重写它们的成本超过了获得的好处，包括执行速度和整个过程的成本效益。

- Rook

是的，速度是关键因素，因为这些库主要用于数值计算。 - astrojuanlu

@Juanlu001 - 人们真喜欢那个术语 :) 有时候这并不重要；例如，如果一个程序每周运行24小时，那么它在两周内不运行...如果它每周运行25小时，没有人会在意... - Rook

1

@Idigas，例如在运营天气预报中，时间更加紧迫，每一个小的加速都非常重要。 - milancurcic

嗯，数字计算听起来像是工程师的早餐。 - astrojuanlu

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- janneb · Accepted Answer

嗯，像“pst”提到的，“它将带来的大量工作”是一个相当重要的原因。

一些其他次要的观点：

LAPACK在现今已成为Fortran 90，因为最新版本不再与F77编译器兼容。也就是说，它远非重写，只有少数更改。
您提到的大部分F90功能使编写强健程序变得更加容易和快速，但并不一定使结果程序更快。
不久之前，没有免费的F90编译器可用（许多人使用g77！），因此对于像LAPACK这样广泛使用的库而言，不使用F90功能可能是一个有意识的决定。
F77编译器通常不会比F90编译器生成更快的代码。如果不是出于其他原因，那么很可能是因为它已经过时，无法针对最新的CPU进行优化。现代Fortran编译器可能从F77创建比从等效的F90程序（使用指针等）更快的代码，但这高度取决于所涉及的程序（例如，使用指针和更复杂的数据结构可以允许使用更好的算法，即使F90程序可能以较低的平均CPU算术单元利用率运行，也可以更快地产生结果）。
向量化，如果您指的是F90+数组语法，则大多数情况下只是一个程序员方便问题，而不是允许更快的代码。一位能干的编译器会同样好地对等效的DO循环进行矢量化。