功能范式与底层硬件之间是否过于分歧，以至于无法达到一般的效率？

Question

来自SO：https://stackoverflow.com/questions/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell的问题的启发

对于FP的许多优点和缺点，这可能是一个长时间的争论，但就目前而言，我想缩小FP在现代硬件上的主要效率的范围。

论文：

功能范式意味着不可变和无状态(?)，但我们运行功能程序的硬件是有状态有限自动机。将“纯功能”程序转换为“有状态硬件”表示给程序员留下了很少的控制，带来了开销(?)并限制硬件功能的使用(?)

我在被质疑的陈述中是对还是错？

可以证明FP在现代通用计算机体系结构上并不意味着主要的性能惩罚吗？

编辑:正如我在回应一些评论时已经说过的，问题不是关于实现性能和细节。在有状态自动机上运行FP可能带来的主要开销是否存在。

Answer 1

在不变性方面存在着巨大的误解。

不可变性是语义的一个特性，但它并不意味着实现中的不可变性。

一个简单的例子是懒惰的实现。

当计算延迟时，表达式的结果在概念上是一个值，但底层实现是包含要求值的参数和用于创建值的函数的thunk，以及用来存储值的槽。

当您第一次(在语言中)询问该值时，将实际执行计算，评估其结果，并将返回给您的值(或句柄)。

这在语言语义中是透明的，您所知道的就是这个变量已经绑定到一个值(或未来的值)，并且一旦完成，您就无法更改将返回的值。底层的内存表示将发生变化，但您将不知道。

在任何语言中都存在相同的语义/实现差异，实际上是优化的核心。不管语言是什么，语义保证了一些东西，而另一些东西则没有具体说明，从而为优化留出了空间。

现在，实际上函数式语言确实没有C++那么快。然而，Go (这仍然是炒作)比Haskell或Lisp慢，C# Mono (来源)也是如此。

当您看到C++或C实现这些性能是多么的不可靠时，您可能希望放弃一点。

当您意识到Haskell正在快速增长，而且它的编译器/运行时仍有很大的优化空间(例如，最近GHC刚刚切换到LLVM -例如，Microsoft Research正在积极资助运行时改进)，您可能愿意打赌它很快就会改进。

有趣：正则表达式的作用或者Haskell团队如何创建一个正则表达式匹配器，它在许多情况下都优于re2 (谷歌的C库)。

Answer 2

功能范式有助于将事物分割在一个狭窄的范围内。考虑到计算机是如何进化的，这是一件非常好的事情。

多核CPU在处理共享资源方面存在很大的问题，同步开销是非常明显的。功能范式允许一种自然的方式来表达没有这些问题的程序。这对并行性确实有好处。

此外，我们越来越多地使用SaaS和云计算的服务器场。因此，同一应用程序必须在多台机器上运行。在这种情况下，同步成本甚至更高。Google已经做了一些工作，并发表了一些关于函数编程和算法的研究论文。这对他们来说是一件关键的事情，因为他们有一个可割裂的问题。

此外，您可以轻松地在计算机堆中进行堆栈，甚至可以使用链接列表进行非连续堆栈。这是在许多编程语言中生成堆栈跟踪时所做的事。所以这不是问题。

好的，函数编程意味着一些限制。但它也带来了自然的方式来表达我们在现代计算中所拥有的问题，这些在范式中是非常难以处理的。可伸缩性就是其中之一，它正在成为一个真正的交易。

每个已经处理复杂并行系统的人都知道我在说什么。

所以我会给出一个细微的答案。是的，功能与现代硬件有问题，但普通的旧编程也有一些问题。像往常一样，你会发现自己的优点和缺点。关键是要知道他们是什么，这样你就可以在必要的时候做出适当的选择。

Answer 3

我没有真正的答案，因为我不知道当前的状态，甚至不知道它会有多难，但是仅仅因为编译器会确保输入中的那些东西，并不一定意味着输出会有它们。理论上，一个足够聪明的编译器可以通过解决所有这些问题，但在实践中，它可能永远存在。

但是，查看它的另一种方法是查看Lisp机器的历史。如果我没记错的话，它们最初的设计目的是克服Lisp与当时机器的不同之处。这些机器的发展最终停止了，因为桌面变得足够快，使低效率的生活比支持另一台机器更便宜。

通常，除了性能最关键的应用程序外，FP语言仍然足够快。如果选择任何较高级别的语言，您将愿意降低微调控制和性能的优先级，以获得更安全、更容易、更易于维护或其他一些优先级。

最后，编程是关于权衡的，所以我们只需要选择对手头的项目更重要的东西。