Suggested algorithm to control upper bound of space "leaks"
marlowsd at gmail.com
Mon Nov 2 08:17:29 EST 2009
On 31/10/2009 21:49, Shelby Moore wrote:
> 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
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!
More information about the Cvs-ghc