> Simon Marlow wrote:
>> The biggest problem with doing this kind of thing is that in order to
>> revert a thunk to its unevaluated state,...
>
Shelby Moore wrote:
> I am suggesting the algorithm would apply only to unevaluated thunks...
>
> I understand you are implying
> ...Thus, an optimization minimization for the target audience.
Typo, "optimization" should be "opportunity cost".
> ...but an upper bound on physical memory and thus paging load.
I do not mean upper bound on paging load. I mean "thus impacting paging
load".
__
> 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 r
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-tr
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?
===
