analisi Spazio per parfib nell'esempio monade-par

Question

Durante la lettura attraverso parfib.hs code su GitHub, ho visto questo commento su allocazione di memoria per la versione monadica:

Monad-par version: 
fib(38) non-threaded: 23.3s 23.1s 
fib(38) 1 thread : 24.7s 24.5s 
fib(38) 4 threads:  8.2s 31.3s 
fib(40) 4 threads: 20.6s 78.6s **240GB allocated** 

non v'è alcun messaggio di carta o blog che spiega questo enorme occupazione di memoria ? L'allocazione di memoria della versione non monadica è documentata nel commento del codice come 17 GB (per fib (42)). Ho cercato tra le carte di monade e presentazione di Simon Marlow ma non ho visto alcuna analisi delle impronte di memoria per parfib.

Answer 1

Penso che sia stato il mio commento nel codice sorgente. Il problema più grande è che l'implementazione predefinita di monad-par utilizza un'architettura elegante ma potenzialmente inefficiente in cui il calcolo Par genera una traccia di azioni Par come una struttura di dati lazy. Questo è ottimo per separare la logica dello scheduler, ma il compilatore non sta completamente deforestando (eliminando) la struttura dei dati intermedia.

Esistono vari modi ben noti per migliorarlo. Ci sta solo prendendo tempo per implementarli. Se si guardano alcuni degli sviluppi recenti (sui rami) nel repository github, stiamo iniziando a popolare monad-par con alcune delle alternative strategie di pianificazione esplorate nel suo lavoro precedente ("Haskell CnC").

Speriamo di cambiare lo scheduler predefinito nella prossima versione principale a qualcosa con un comportamento parfib significativamente più vicino a "raw" par/pseq.