函数式编程语言是否有更多的机会进行编译时优化？

Question

我当时正在读一本书“面向现实世界的函数式编程”。它首先比较命令式语言和函数式编程语言。并阐述了函数编程中的“值”和“表达式”与命令式编程中的“变量”和“函数”是如何不同的。从讨论中我想出了一个想法-

函数式编程语言比它们的命令式语言有更多的机会进行编译时优化。

是真的吗？

Answer 1

函数式编程语言进行了更多的编译时间优化。原因之一是纯度-并发是微不足道的，因为没有状态。因此，编译器可以在不改变程序行为的情况下，轻松地获得两个分支并并发它们。

同时，任何可以在没有状态的情况下计算的计算(即haskell中的非一元计算)都可以由编译器提前计算，但是这样的计算可能很昂贵，因此可能只完成了部分计算。

此外，任何不需要计算的东西都可以完全优化出程序。

Answer 2

原则上，函数语言比其命令式语言具有更多的编译时优化可能性，这可能是正确的。

不过，更有趣的是，如果它们实际上是在当前编译器中实现的，以及这些优化在实践中的相关性(即在生产环境中使用预先可预测的编译器设置的惯用“真实生活(TM)”代码的最终性能)。

例如，Haskell为臭名昭著的电脑语言基准游戏提交的材料(尽管它可能很糟糕--但并不是说目前有任何更好的东西)给人的印象是，大量的时间花在手工优化上，这与“由于insert some property about FP languages here可能的编译器优化”的说法相反，使得优化看起来更像是理论上的可能性，而不是相关的现实。

不过，我很高兴在这一点上被证明是错误的。

Answer 3

在函数样式中，通过程序的值流非常非常明显(对编译器和程序员都是如此)。这给编译器很大的回旋余地，可以决定在哪里存储值，保留值多长时间，等等。

在命令式语言中，编译器向程序员承诺建立一个模型，其中大多数变量对应于内存中的实际位置，这些位置在定义的生存期内保持不变。有可能，任何语句都可以从(或写入！)中读取！这些位置中的任何一个，因此编译器只能用寄存器分配替换内存位置，将两个变量合并到单个存储位置，或者在对程序中可能引用的变量的其他位置进行艰苦分析之后执行类似的优化。

现在，有两个注意事项：

• 编程语言社区已经花费了(浪费？)在过去的五十年里，在开发聪明的方法来做这一分析方面付出了大量的努力。有一些众所周知的技巧，如寄存器着色等等，可以在大多数时间内完成一些更容易的情况；但是，这使得大型的、缓慢的编译器和编译的复杂性不断权衡，从而提高了代码的质量。
• 同时，大多数函数式编程语言也不完全是功能性的；许多程序实际上需要做的事情，比如响应I/O本身是非功能性的，所以没有一个编译器能够完全摆脱这些技巧，而且没有任何语言能够完全避免它们--甚至Haskell，它对我的品味来说也太纯了(您的里程数可能会不同)，只能控制和隔离代码中的非功能部分，而不是完全避免它们。

但是要回答一般的问题，是的，函数式范例给编译器很大的自由去优化它在命令设置中没有的。