Question

有没有理由相信fortran内部函数比外部函数表现更好？

e.g。

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

VS

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

例如，内部单元是否允许编译器将代码内联为某种宏？

Answer 1

我不相信有任何一般原因相信Fortran内部函数的性能优于外部函数。 一般原因我的意思是适用于所有平台上所有符合Fortran标准的编译器。所以我不相信人们可以在表现方面表达对内部而非外部功能的一般性（在同一意义上）偏好。

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

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

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

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

Answer 2

对于可能引发争议的事情......有一种暗示，内部程序“执行”比标准中的外部程序更好，但不是你（可能）意味着的意义。

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

在一般情况下，自动显式界面产生的程序稳健性优势（非常多的一种性能）会消除任何“执行速度”性能考虑因素，这些日子最好来了至于“它取决于”/“你需要测量以找出”/“对于任何体面的编译器来说可能没有区别。”

在这种情况下使用bar（和foo）作为模块过程可能会更好 - 因为它消除了foo变量的非预期主机关联，并允许独立测试bar。

程序类型的选择应基于源代码的技术要求（编写外部程序的正当理由至今仍保留在现代Fortran代码库中，但它们是非典型的），其次是鲁棒性和模块与内部程序可能提供的结果源代码的清晰度。如果您需要考虑此决策中的执行速度性能，那么您的编译器就会崩溃。

内部功能的表现

2 个答案: