Replacement for GMP: Update

Bulat Ziganshin bulat.ziganshin at gmail.com
Sat Aug 12 08:58:26 EDT 2006


Hello skaller,

Saturday, August 12, 2006, 12:34:54 PM, you wrote:

>> > My point here is that actually this is a disastrous optimisation
>> > in a  multi-processing environment, because in general, the
>> > assignment of a pointer means the store isn't write once.
>> 
>> :)  all the variables rewritten is local to the function. _without_
>> tail call optimization, we create new stack frame for each recursive
>> call. _with_ optimization, we just update vars in the first stack
>> frame created because we know that these vars will not be reused after
>> return from call

> Yes, but this defeats the use of the kind of collector I attempted
> to describe. 

> The problem will occur if the 'stack' is aged: in that case
> the sweep can miss the mutation and reap a live object.

well, i don't know how updatable vars in stack interoperate with GC.
let's someone else answer this question. but afaik GHC 6.5 supports
multi-cpu execution of multiple Haskell threads (which makes it a
better language for modern multi-core cpus), tail-call optimization
and 2-generation GC (actually, it supports any number of generations).
also, GHC supports mutable arrays. you search GHC bug tickets for one
that optimized GC with mutable vars: in ghc64 _each_ GC, including
minor ones need to scan _every_ updatable reference (IORef/STRef) and
_each_ element of _every_ updatable array (IOArray/STArray) and this
significantly slowdowns many programs, including GHC itself. in ghc65
better scheme now used

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Glasgow-haskell-users mailing list