Re: [Caml-list] Ocaml and games

[Thatcher Ulrich <tu@tulrich.com>]

On Fri, 25 Jan 2002, Chris Hecker wrote:

> > The GC performance predicability and smoothness is a huge looming
> > shadow on the horizon that may or may not materialize, I have no
> > idea.  Do you have any specific thoughts on this that you can
> > share yet?  Have you done any tests?
>
> Nope.  It's just that the "conventional wisdom" is that GC will hurt
> performance, so I'm worried just on principle. :) I haven't seen any
> indication that it will yet, however.
>
> As the other poster said, doing full collections between levels
> seems like a reasonable thing to try.
>
> I'm also slightly worried about the "write barrier" thing, which
> I've seen posted about but don't fully understand yet.  To avoid GC
> activity I may want to keep some arrays around and reuse them, but
> apparently as they migrate into the old heap then you get the write
> barrier thing going on.  Hopefully this won't be a problem either,
> but I don't know yet (I don't know if I understand it correctly yet,
> either).

I have no real-world experience to share concerning OCaml's garbage
collector, but there's an informal description of how it works here:

http://para.inria.fr/~doligez/caml-guts/Sestoft94.txt

It's linked off the "Papers" section of the OCaml web site:

http://caml.inria.fr/ocaml/papers.html

Anyway, I'll speculate, because I've long pondered using GC in games:
based on that description, OCaml's GC is *exactly* the ideal type of
collector for interactive games.  It's generational, which is good for
overall efficiency, and the old generation is collected incrementally,
which means it processes a single "chunk" at a time, rather than the
full heap.  I haven't even looked at the API, but in theory the ideal
way to run a collector like this in a double-buffered game program
(like many console games) is to:

1) make sure the worst-case time to process a chunk is under say 2ms.
Do this by sizing the chunks appropriately or whatever.  Disclaimer: I
have no idea what Ocaml GC's real-world latency is for processing a
chunk.

2) at the end of rendering, before displaying the back buffer, look at
the timer and decide whether you have 2ms to spare before the next
vsync.  If so, then run the GC for one chunk -- it's practically free.
If not, then don't; hopefully you'll catch up in subsequent frames.

Basically, if your average allocation rate is below some threshold
(and you have some extra room on the heap to amortize any peaks), and
you run the GC enough, you'll *never* see a GC pause.

If you're triple-buffered, or you don't wait for vsync, then this
trick doesn't work, but in those cases you probably care much less
about an extra 2ms GC latency now and then.

The deal with a write barrier is that any time you write to a pointer
variable that's stored in the old generation of the heap, the GC must
know about it (so it can keep its incremental state synchronized).  If
you're reading, or just writing data variables, the write barrier
should be irrelevant (although I don't know how it's implemented in
practice, so I'll shut up now).

-Thatcher

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr