功能范式与底层硬件是否过于分散，以至于总体上效率不高？

受到SO中一个问题的启发：https：//stackoverflow.com/questions/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

关于FP的众多优点和缺点可能是一个漫长的辩论，但就目前而言，我想将FP 的范围缩小到现代硬件上FP的主要效率。

论文：

功能范式意味着不变性和无状态性（？），但是我们运行功能性程序的硬件是有状态的有限自动机。将“纯功能”程序转换为“有状态硬件”表示形式后，程序员几乎无法控制，带来了开销（？），并限制了硬件功能（？）的使用。

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

是否可以证明FP确实/不暗示对现代通用计算机体系结构的主要性能损失？

编辑： 正如我已经在回答某些评论时所说的那样，问题不在于实现性能和细节。这与是否存在主要开销有关，在有状态自动机上运行FP可能会带来这些开销。

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

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

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

懒惰的计算时，表达式的结果从概念上讲是一个值，但是底层实现是一个thunk，其中包含要评估的参数和创建值的函数，以及用于存储值的插槽。

第一次（用语言）询问值时，将实际执行计算，评估结果并将值返回给您（或句柄）。

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

几乎任何语言都存在相同的语义/实现差异，并且实际上是优化的核心。不管使用哪种语言，语义都可以保证某些事情，但没有指定其他东西就可以留出优化的空间。

现在，确实可以使用的实用语言不如C ++快。但是，Go（仍然相当大肆宣传）比Haskell或Lisp慢，C＃Mono（源代码）也慢。

当您看到C ++或C不能可靠地获得这些性能时，您可能希望放手一点。

当您意识到Haskell如今发展迅速，并且其编译器/运行时仍有很多优化空间（例如，GHC最近才切换到LLVM时，Microsoft Research正在积极资助运行时改进），您可能会打赌它将很快改善。

乐趣：在多种情况下进行正则表达式播放或Haskell团队如何创建比re2Google C库更好的正则表达式匹配器。

功能范式可用于在狭窄范围内拆分事物。考虑到计算机如何发展，这确实是一件好事。

多核CPU在处理共享资源方面存在很大的问题，同步成本确实很高。函数范式提供了一种自然的方式来表达没有那些问题的程序。这对于并行性真的很好。

此外，我们越来越多地将服务器场与SaaS和云计算一起使用。因此，同一应用程序必须在多台计算机上运行。在这种情况下，同步成本甚至更高。Google已经完成了一些工作，并发表了一些有关可以编写的函数式编程和算法的研究论文。这对他们来说很关键，因为它们存在可调用性问题。

而且，您可以轻松地在计算机堆中进行堆栈，甚至可以使用链表在不连续的堆栈中进行堆栈。这已经做好了用多种编程语言生成堆栈跟踪的准备。因此，这不是问题。

好的，函数式编程意味着一些限制。但这也带来了自然的方式来表达我们在现代计算机中遇到的问题，这些问题在习惯于范式的情况下极难处理。可伸缩性是其中之一，并且已经成为现实。

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

因此，我会细化答案。是的，功能与现代硬件有关，但是普通的旧编程也有一些问题。与往常一样，您会发现优点和缺点。关键是要知道它们是什么，以便您在需要时可以做出适当的选择。

我真的没有答案，因为我不知道当前状态，甚至不知道它会有多困难，但仅仅是因为编译器将确保输入中的内容，并不必然意味着输出中会有它们。从理论上讲，一个足够聪明的编译器可以解决所有这些问题，但实际上，它可能永远存在。

但是，另一种查看方式是查看Lisp机器的历史。如果我没记错的话，它们最初的设计目的是克服Lisp与当时的机器存在的相同问题。这些计算机的开发最终停止了，因为台式机变得足够快，使得效率低下比支持另一台计算机便宜。

通常，除了对性能要求最高的应用程序外，FP语言仍然足够快。选择任何高级语言，您将愿意降低微调控制和性能的优先级，以获得更安全，更轻松，更可维护或其他优先级。

最后，编程就是权衡取舍，因此人们只需要选择对当前项目更重要的事情。

函数范式确实暗示了不变性和无状态性，但是我们没有任何完全纯净的编程语言。即使是最纯正的Haskell，也会产生副作用。

就是说，为了回答您有关效率的问题，我同时使用了Haskell和Clojure，但都没有注意到两者的任何性能问题。