7

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

是因为 FORTRAN 77 编译器产生了更优化的代码，也许它更适合并行执行？请注意，我什至不是在谈论 Fortran 2003，它只有8 年的历史：我在谈论 Fortran 90，所以我假设它已经足够广泛并且编译器已经准备好。反正我没接触过这个行业。

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

4

4 回答 4

18

好吧，就像提到的“pst”一样，“它会带来大量工作”是一个非常重要的原因。

一些进一步的小点：

  • 如今，LAPACK 是 Fortran 90，因为最新版本不再使用 F77 编译器进行编译。话虽如此，它远非重写，只是改变了一些东西。

  • 您提到的大多数 F90 功能使编写健壮的程序变得更容易和更快，而不必使生成的程序更快。

  • 不久前还没有免费的 F90 编译器（很多人使用 g77！），因此对于像 LAPACK 这样广泛使用的库来说，不使用 F90 功能可能是一个有意识的决定。

  • F77 编译器通常不会产生比 F90 编译器更快的代码。如果不是出于任何其他原因，那是因为它可能已经过时并且无法针对最新的 CPU 进行优化。现代 Fortran 编译器从 F77 创建的代码可能比从等效的 F90 程序创建的代码更快，后者广泛使用指针等，但这高度依赖于所讨论的程序（例如，使用指针和更高级的数据结构可能允许使用更好的算法，允许 F90 程序更快地产生结果，即使它可能在 CPU 算术单元的平均利用率较低的情况下执行）。

  • 向量化，如果你指的是 F90+ 数组语法，主要是程序员的方便问题，而不是允许更快的代码。一个称职的编译器也会向量化等效的 DO 循环。

于 2012-01-02T22:53:58.717 回答
6

没有理由投入大量工作来（也许）改进一些运作良好的东西。需要注意的是，尽管 Fortran 90 引入了许多新特性，但它并没有改变语言。请记住，Fortran 90 Standard 向后兼容 FORTRAN 77。现代编译器也能够优化 FORTRAN 77 代码。Fortan 90 中引入的一些特性（例如指针）会阻碍效率，如果人们关心执行时间，例如在 HPC 中，应该避免这些特性。

所以它不会真正有所作为。对于现代编译器，写得好的 FORTAN 77 也同样可优化——它就像一块没有糖霜的蛋糕。在这里，在 Fortran 90 及更高版本的情况下，结冰看起来比尝起来更好——这对程序员来说是一种方便，但不一定能提高程序效率。

于 2012-01-02T22:56:33.177 回答
5

Fortran 77 程序可能更快的主要原因之一是：

分配的数组 (Fortran 90) 比在编译时声明的数组慢得多。两者都没有放在内存中的同一位置。这就是 Fortran 中的堆栈与堆内存管理。

例如见这里

话虽如此，Fortran 90+ 具有快速的“全块”数组操作。我是 gcc-fortran (gfortran) 的忠实粉丝，并且没有任何编译选项，对于大小为 N 的数组 a

a = a + 1

速度是 4 倍

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

这张长凳适合我，在我的机器上，在没有优化选项的 gfortran 上，并且没有任何声称这是专业的基准测试。

分配“问题”（不是问题而是特性）不是架构、编译器或任何与 Fortran 标准相关的东西。

于 2012-01-03T20:57:00.470 回答
1

F77 程序是否会比等效的 F90 程序更慢或更快，用新的语法重写是可以讨论的，但现在让我们忽略它。

然而应该考虑的是，没有人真正关心速度。人们只关心相关情况下的执行速度，以及商业盈利的情况（我确信有一个更好的术语，但现在没有想到......也许具有成本效益）。

由于这两个（相当流行的库）仍在 F77 中，很明显，普遍认为重写它们的成本超过了所获得的好处、执行速度方面的好处以及成本效益方面的好处。整个过程。

于 2012-01-02T22:53:55.927 回答