Re: [Caml-list] concurrent gc?

[Goswin von Brederlow <goswin-v-b@web.de>]

On Wed, Jul 23, 2014 at 11:58:57PM -0600, Anthony Tavener wrote:
> I agree with Malcolm's experience, and my situation might be similar to
> yours: games -- a lot of allocations at high framerate. I'm guessing this
> from how evil you consider pauses to be. ;) In some circumstances I *have*
> experienced hitching, which did turn out to be due to GC -- but then I'd
> find I was creating a pathological case. You can't expect to throw a
> completely arbitrary workload at the GC and expect it to remain invisible.
> Just as with allocations by hand in C, even with sophisticated custom
> allocators -- you still need to use dynamic allocations wisely. Here, I
> think the biggest problem is when you have a GC, you lose awareness of the
> allocations you're triggering.
> 
> I doubt I'd use OCaml to write the bulk of a leading-edge (in graphics
> fidelity, framerate, and scene size) FPS game engine, competing with Unreal
> or Crytek... but it's suitable for less intensive requirements. Then again,
> one might follow the approach of FFTW and use OCaml to write a generator
> which outputs a C-based renderer. :D

Actually what you need to do there is to trigger the GC explicitly
inbetween frames and fine tune the GC so it doesn't run mid-frame at
all (make the minor heap large enough).

That also tends to improve the GC efficiency since for a frame you
will have lots of temporary allocations that won't outlive the frame.
So at the end of each frame is the best time to clean up the minor
heap.

MfG
	Goswin