0

有没有理由相信 fortran 内部函数会比外部函数执行得更好？

例如

subroutine foo(x,y)
   real :: x
   x = bar(y)
   return
   contains
   real function bar(x)
      real :: x
      bar = x*x
      return
   end function bar
end subroutine foo

对比

subroutine foo(x,y)
   real :: x
   real :: bar
   x = bar(y)
   return
end subroutine foo

real function bar(x)
   real :: x
   bar = x*x
   return
end function bar

例如，内部单元是否允许编译器像某种宏一样内联该代码？

4

2 回答 2

2

我不相信有任何普遍的理由相信 Fortran 内部函数会比外部函数执行得更好。一般来说，我的意思是适用于所有平台上所有符合 Fortran 标准的编译器。因此，我不相信人们可以基于性能来表达对内部功能而非外部功能的一般（在相同意义上）偏好。

我会更进一步，我认为语言标准（其中任何一个）中没有太多内容可以很好地支持关于实现相同功能的变体方法的相对性能的论点。因此，再举一个例子，我认为该标准不会允许人们争论显式do循环应该优于等效的基于数组语法的表达式。或者反驳。

但我确实相信，可能存在特定于编译器版本和/或平台的原因，出于性能考虑，一种方法优于另一种方法。例如，上次我在英特尔处理器上的 MS Windows 上测试英特尔 Fortran 编译器（可能是 v11.something）时，我得出结论，显式do循环通常优于等效的数组语法表达式。

由于性能通常是 Fortran 程序员关注的一个关键问题，因此我们有必要在编译器的开发过程中监控各种方法的性能，而不是陷入过时的性能想法。

在这个游戏中，硬数据总是胜过争论。程序性能是一门实验科学。

于 2013-01-18T19:14:47.560 回答
1

对于可能有争议的事情......这暗示内部程序“执行”比标准中的外部程序更好，但不是您（可能）的意思。

内部过程和模块过程获得自动显式接口。这要求编译器检查每个过程引用的某些方面，并使大多数半体面的编译器能够检查许多其他方面。使用外部程序实现相同级别的检查需要手动提供接口，这很容易出错。

在一般情况下，由自动显式接口产生的程序健壮性好处（很大程度上是一种性能形式）消除了任何“执行速度”性能考虑，这些天充其量归结为“它取决于”/“你”对于任何体面的编译器，都需要测量以找出“/“可能没有区别”。

在这种情况下，将 bar（和 foo）作为模块过程可能会更好 - 因为它消除了变量与 foo 的意外主机关联，并启用了 bar 的独立测试。

程序类型的选择应基于源代码的技术要求（在现代 Fortran 代码库中仍然存在编写外部程序的正当理由，但它们是非典型的），然后是在健壮性和清晰性之间进行权衡生成的源代码可能由模块提供，而不是内部过程。如果您需要在此决定中考虑执行速度性能，那么您的编译器就会损坏。

于 2013-01-18T20:15:53.730 回答