On 31/10/2009 21:49, Shelby Moore wrote:
http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Shelby Moore wrote:
One possible runtime optimization to provide an upper bound for cache
control, might be to not cache thunks when the runtime computation time
times number of cache hits, is less than the round-trip paging time
multiplied by recent system paging load.
Is this novel? Is it useful?
Clarify and improve:
One possible idea for runtime optimization to provide a more deterministic
upper bound on paging load for cache control, might be to not cache
thunk-wise when for each thunk, the total tree of computation time under
the thunk multiplied by the number of cache hits on the thunk, is less
than the round-trip paging time of thunks under the tree multiplied by a
chosen factor of recent system paging load. Or toggle the test on and off
on a chosen threshold of recent system paging load.
The biggest problem with doing this kind of thing is that in order to
revert a thunk to its unevaluated state, you have to retain the thunk's
free variables, which itself may cause a space leak, though perhaps by
reverting thunks recursively in the free variables you could limit the
damage. The case where this isn't an issue is top-level thunks (CAFs).
Measuring the things you mention is quite problematic and might add
further overheads.
Running in a low-virtual-memory situation is not something that GHC does
well at all, though I do wonder how useful it is in practice. I suspect
that people won't be willing to pay a performance overhead for the
possibility of better behaviour when the heap grows larger than real
memory, so anything you do has to be essentially free in the common case.
Don't let me put you off though!
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
