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<[email protected]> 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.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
