编译器对于命令式语言的功能语言优于编译器的优点 [英] Advantages of compilers for functional languages over compilers for imperative languages
问题描述
作为这个问题的后续 F＃相对于C＃的内置不变性的优点是什么？ - 我正确地假设F＃编译器可以使某些优化知道它处理大部分不可变的代码？我的意思是即使开发人员编写Functional C＃，编译器也不会知道开发人员尝试编码的所有不变性，以至于无法进行相同的优化，对吧？
一般来说，函数式语言的编译器能够进行优化，这对命令式语言来说是不可能的 - 即使是用尽可能多的不变性编写的语言也是如此。
我会在很大程度上说'不'。
当你看到 ... f（x）... f（x）...这样的代码时，你从不变性或引用透明性中获得的'优化'优点就像是能够执行'通用子表达式消除'一样。 。但是如果没有非常精确的信息，这种分析很难做到，而且由于F＃在.Net运行时运行，而.Net无法将方法标记为纯粹（无效），因此需要大量内置信息和分析甚至试图做任何这样的事情。另一方面，像Haskell这样的语言（其中大多数意思是'Haskell'，因为Haskell几乎没有语言''，任何人都听说过或使用过:)，这是懒惰和纯粹的，分析更简单（一切都是纯粹的，坚持不懈）。
也就是说，这样的优化'经常可以与系统的其他有用方面（性能可预测性，调试，...）进行严重的交互。
经常会有足够聪明的编译器可以做的事情X，但我的观点是足够聪明的编译器永远是一个神话。如果你想快速的代码，然后写快速的代码;编译器不会拯救你。如果你想消除常见的子表达式，然后创建一个局部变量（自己动手）。
这大部分是我的看法，欢迎你不要低估或不赞同（的确我听说'多核'被认为是一个潜在的'优化可能再次变得性感'的上升原因，这听起来似乎是合理的）。但是，如果您对任何编译器进行任何不平凡的优化（源代码中的注释都不支持这种优化）抱有希望，那么请准备等待很长很长的时间，以实现您的希望。
不要误解我的意思 - 不变性很好，很可能会帮助您在许多情况下编写快速代码。但并不是因为编译器优化它 - 而是因为代码易于编写，调试，获得正确，并行化，配置文件以及决定哪些是花费时间最重要的瓶颈（可能会重写它们）。如果您想要高效的代码，请使用开发流程，以便快速开发，测试和配置文件。
As a follow up to this question What are the advantages of built-in immutability of F# over C#?--am I correct in assuming that the F# compiler can make certain optimizations knowing that it's dealing with largely immutable code? I mean even if a developer writes "Functional C#" the compiler wouldn't know all of the immutability that the developer had tried to code in so that it couldn't make the same optimizations, right?
In general would the compiler of a functional language be able to make optimizations that would not be possible with an imperative language--even one written with as much immutability as possible?
I would say largely 'no'.
The main 'optimization' advantages you get from immutability or referential transparency are things like the ability to do 'common subexpression elimination' when you see code like ...f(x)...f(x).... But such analysis is hard to do without very precise information, and since F# runs on the .Net runtime and .Net has no way to mark methods as pure (effect-free), it requires a ton of built-in information and analysis to even try to do any of this.
On the other hand, in a language like Haskell (which mostly means 'Haskell', as there are few languages 'like Haskell' that anyone has heard of or uses :)) that is lazy and pure, the analysis is simpler (everything is pure, go nuts).
That said, such 'optimizations' can often interact badly with other useful aspects of the system (performance predictability, debugging, ...).
There are often stories of "a sufficiently smart compiler could do X", but my opinion is that the "sufficiently smart compiler" is, and always will be, a myth. If you want fast code, then write fast code; the compiler is not going to save you. If you want common subexpression elimination, then create a local variable (do it yourself).
This is mostly my opinion, and you're welcome to downvote or disagree (indeed I've heard 'multicore' suggested as a rising reason that potentially 'optimization may get sexy again', which sounds plausible on the face of it). But if you're ever hopeful about any compiler doing any non-trivial optimization (that is not supported by annotations in the source code), then be prepared to wait a long, long time for your hopes to be fulfilled.
Don't get me wrong - immutability is good, and is likely to help you write 'fast' code in many situations. But not because the compiler optimizes it - rather, because the code is easy to write, debug, get correct, parallelize, profile, and decide which are the most important bottlenecks to spend time on (possibly rewriting them mutably). If you want efficient code, use a development process that let you develop, test, and profile quickly.
这篇关于编译器对于命令式语言的功能语言优于编译器的优点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
