“ CPS”方法严重损害了SML / NJ的性能；所需的推理

在对学习F＃ 的评论中：使用其他编程语言的哪些书籍可以翻译为F＃以学习功能概念？Makarius说：

请注意，“ CPS”方法对SML / NJ中的性能造成了很大的损害。它的物理评估模型违反了硬件中内置的太多假设。如果您采用Isabelle / HOL之类的SML大型符号应用程序，则带有CPS的SML / NJ大约会问世。比传统堆栈的Poly / ML慢100倍。

有人可以解释原因吗？（最好有一些示例）这里是否存在阻抗不匹配？

最初近似时，当程序仅以CPS样式在堆上向前运行，而不是传统的堆栈增长和收缩时，内存访问的“局部性”有所不同。还要注意，CPS将始终需要GC来恢复放置在堆上的看似本地数据。10或20年前，当硬件比今天简单得多时，仅这些观察就足够了。

我自己既不是硬件专家，也不是编译专家，因此，作为第二种近似，这是导致近似的一些具体原因。Isabelle / HOL中的100因子：

• 根据上面的“第一近似值”的基本性能损失。

• SML / NJ堆管理和GC存在严重问题，无法扩展到数十MB。Isabelle现在通常使用100-1000 MB，有时使用几GB。

• SML / NJ编译非常慢-这可能是完全无关的（请注意，Isabelle / HOL会替换运行时编译和运行代码）。

• SML / NJ缺少本机多线程-并非完全不相关，因为CPS被广告宣传为“在用户空间中滚动自己的线程而没有单独的堆栈”。

Morriset / Tolmach PPOPP 1993在“ Procs and Locks：新泽西州标准ML的便携式多处理平台”（CiteSeerX）的论文中还讨论了堆和线程的相关性。注意：CiteSeerX的PDF向后，从10 1代替1-10。