函数式编程语言和现有硬件(寄存器机)的设计原则是否相反？

Question

函数式语言寻求最小化偶然状态(计算方便但逻辑上不必要数据依赖)，方法是认可最细粒度的模块化、数学化的一目了然结构。然而，通用寄存器机器通过最大化数据依赖来实现最大的时间/空间效率，因为这允许CPU使用手头的数据，而不是支付额外的上下文切换到提取过程的成本。

要将数据依赖的最小化转化为性能优势，就必须使用这些附加的保证来追求更大的并行性，而不必惩罚抽取堆栈(这里和这里)或基于队列的(这里和这里)架构中的小型匿名过程。芯片设计还没有朝着这些方向发展，因为摩尔定律和丹纳德尺度在历史上使并行化成为一种经济上的输赢游戏(尽管这种情况可能很快就会改变)。

当

所提供的性能优势与硬件制造商

的优先级相冲突时，像Haskell (或小猫)这样的函数式语言的性能可以超过主流语言。

Answer 1

函数式编程本质上并不是低效的。语言语义没有理由必须与底层执行模型紧密匹配，尽管更紧密的匹配肯定会使编译更容易。

例如，Haskell现在已经可以提供良好的性能，但是优化是一件难事:很难编写能够可靠编译成优化良好的机器代码的Haskell代码。问题不在于Haskell是一种函数式语言，而是Haskell具有相当复杂和非常高级的语义，特别是像惰性计算这样的不寻常特性。其他功能语言是非常动态的，并且不具有允许生成高效代码的类型系统，例如JavaScript。

但是FP语言没有这些复杂的语义特性，例如ML语言家族有非常有趣的静态类型命令式函数语言，如OCaml。除了必须处理闭包之外，编译OCaml与编译C没有根本区别，而且C还有一些有问题的特性，限制了它在当前硬件上的效率，例如指针混叠。

如果函数式语言有问题的特性w.r.t。高效的执行，这是垃圾回收的需要。例如，不可变的数据结构、闭包和延续都会在以下情况下受益：

• 未引用的数据可以廉价地垃圾收集。
• 可能:数据可以廉价复制，例如通过复制即写(CoW)。
• 不假定堆栈存在的执行模型

这些东西原则上可以移动到硅上，例如带有硬件GC的MMU芯片，以及支持CoW的内置虚拟寻址。(是的，我知道CoW页面，但在这里还不够细。)然而，这将意味着一个与今天使用的完全不同的内存模型。我怀疑这是否会比目前的先进技术更有效，但它可能允许比在当前硬件上更有效地执行功能和面向对象的程序。

但这是不可能的，因为规模经济有利于现状。很久以前，有功能编程硬件：Lisp机。由于Lisp需求的下降，以及微处理器(如x86芯片)的出现，这些问题几乎完全消失了:微处理器已经足够快了。构建优秀的编译器比开发具有竞争力的芯片更便宜。出于类似的原因，硬件JVM从来没有真正抓住过(尽管Java平台确实如此，比如Android和许多功能手机)。