「CPS」アプローチは、SML / NJのパフォーマンスに大きな悪影響を与えました。推論が望ましい

Learning F＃ へのコメント：関数の概念を学ぶために、他のプログラミング言語を使用してF＃に翻訳できる書籍はどれですか。マカリウスは述べた：

「CPS」アプローチは、SML / NJのパフォーマンスに大きな悪影響を与えていることに注意してください。その物理的評価モデルは、ハードウェアに組み込まれているあまりにも多くの仮定に違反しています。Isabelle / HOLのようなSMLの大きなシンボリックアプリケーションを使用する場合、CPSを使用したSML / NJは約5倍になります。従来のスタックのPoly / MLよりも100倍遅い。

誰かがこの理由を説明できますか？（できればいくつかの例で）インピーダンスの不一致はありますか？

最初の概算では、プログラムが従来のスタックの拡大と縮小ではなく、CPSスタイルのヒープ上で実行するだけの場合、メモリアクセスの「局所性」に違いがあります。また、CPSは、ヒープ上に配置された一見ローカルなデータを回復するために、常にGCを必要とすることに注意してください。これらの観察だけでも、ハードウェアが今日よりもはるかに単純だった10年または20年前には適切でした。

私自身はハードウェアでもコンパイラの第一人でもありません。そのため、2番目の近似として、約の具体的な理由を以下に示します。Isabelle / HOLに見られる係数100：

• 上記の「最初の近似」による基本的なパフォーマンスの損失。

• SML / NJヒープ管理とGCには、数十MBを超える拡張が困難な問題があります。Isabelleは現在100〜1000 MBを日常的に使用しています。

• SML / NJコンパイルは非常に低速です-これは完全に無関係である可能性があります（Isabelle / HOLはランタイムコンパイルと実行コードを代替することに注意してください）。

• CPSは「独自のスレッドを個別のスタックなしでユーザー空間にロールする」と宣伝されたため、SML / NJにはネイティブマルチスレッドがありません。

ヒープとスレッドの相関については、Morriset / Tolmach PPOPP 1993のペーパー「Procs and Locks：A Portable Multiprocessing Platform for Standard ML of New Jersey」（CiteSeerX）でも説明されています。 1-10ではなく1。