L'approccio "CPS" ha arrecato gravi danni alle prestazioni in SML / NJ; ragionamento desiderato

In un commento all'apprendimento di F #: quali libri che usano altri linguaggi di programmazione possono essere tradotti in F # per apprendere concetti funzionali? Makarius dichiarò:

Si noti che l'approccio "CPS" ha arrecato gravi danni alle prestazioni in SML / NJ. Il suo modello di valutazione fisica viola troppe ipotesi integrate nell'hardware. Se prendi grandi applicazioni simboliche di SML come Isabelle / HOL, SML / NJ con CPS esce ca. 100 volte più lento di Poly / ML con il suo stack convenzionale.

Qualcuno può spiegare le ragioni di questo? (Preferibilmente con alcuni esempi) Esiste una discrepanza di impedenza qui?

— Guy Coder
fonte

La mia comprensione è che l'hardware assume una disciplina di stack, e quindi l'approccio CPS ha un successo performace per non aderire a questo presupposto. Ma questa è solo la mia opinione disinformata.

— Andrej Bauer,

A prima approssimazione, c'è una differenza nella "località" dell'accesso alla memoria, quando un programma si sposta in avanti sull'heap in stile CPS, invece della tradizionale crescita e riduzione dello stack. Si noti inoltre che CPS avrà sempre bisogno di GC per recuperare i dati apparentemente locali inseriti nell'heap. Queste osservazioni da sole sarebbero state adeguate 10 o 20 anni fa, quando l'hardware era molto più semplice di oggi.

Non sono me stesso né un hardware né un guru del compilatore, quindi come seconda approssimazione, ecco alcuni motivi concreti per ca. fattore 100 visto in Isabelle / HOL:

Perdita di prestazioni di base secondo la "prima approssimazione" sopra.
La gestione dell'heap SML / NJ e GC presenta gravi problemi di scalabilità oltre diverse decine di MB; Isabelle ora utilizza regolarmente 100-1000 MB, a volte diversi GB.
La compilazione SML / NJ è molto lenta - potrebbe non essere completamente correlata (notare che Isabelle / HOL alterna compilazione di runtime e codice in esecuzione).
SML / NJ manca di multithreading nativo - non completamente non correlato, poiché CPS è stato pubblicizzato come "arrotolare i propri thread nello spazio utente senza stack separati".

La correlazione di heap e thread è anche discussa nel documento di Morriset / Tolmach PPOPP 1993 "Procs and Locks: A Portable Multiprocessing Platform for Standard ML of New Jersey" ( CiteSeerX ) Nota: PDF di CiteSeerX è all'indietro, pagine da 10 a 10 1 invece di 1-10.

— Makarius
fonte