[Haskell-cafe] Re: Real-time garbage collection for Haskell

Simon Marlow marlowsd at gmail.com
Tue Mar 2 08:55:07 EST 2010

On 01/03/2010 14:16, Sönke Hahn wrote:
> On Monday 01 March 2010 01:04:37 am Luke Palmer wrote:
>> On Sun, Feb 28, 2010 at 2:06 AM, Pavel Perikov<perikov at gmail.com>  wrote:
>>> Did you really seen 100ms pauses?! I never did extensive research on this
>>> but my numbers are rather in microseconds range (below 1ms). What causes
>>> such a long garbage collection? Lots of allocated and long-living
>>> objects?
>> This is all hypothetical right now.  I heard some horror stories in
>> which people had to switch to the main game loop in C++ and only do
>> the AI logic in Haskell because of pauses.  I would rather not do
>> that, especially because this project is *about* proving Haskell as a
>> viable game development platform.  So I am trying to be prepared if I
>> do see something like that, so that it doesn't put the show on hold
>> for a few months.
>> Presumably large, long-living objects would cause the generation 0
>> collections to take a long time.  I am not sure if we will have any
>> said objects, but we can't rule it out...
>> Thanks for the positive reassurances, at least.  I'd like to hear from
>> people with the opposite experience, if there are any.
> Yes there are. I am working on a game with Haskell using OpenGL rendering.
> I've done some frame time measurements lately and encountered single frames
> needing more than 100ms to be rendered. I am currently trying to gather
> information on what is going on in these 100ms and why. From what i
> understand, the GC is running very often and just some (very few) of its runs
> are very slow.
> BTW: switching to parallel GC (either with -N1 or -N2 (on a dual core
> machine)) made the behavior MUCH worse, for some reason.

Probably due to cache effects - shipping the data off to a different 
core in the GC can far outweigh any benefits you would have got by 
traversing the heap in parallel.  For a single-threaded program, 
parallel GC tends to only help when the heap gets large (over 50MB at a 
guess).  For parallel programs, parallel GC helps by keeping the data in 
the right cache.

I'm finding that for parallel programs turning off load-balancing with 
+RTS -qb often helps, because load-balancing is bad for locality. 
Again, if the heap gets large, then collecting it in parallel is 
probably more important than keeping it in the cache.


More information about the Haskell-Cafe mailing list