[gambit-list] Video game written in Gambit
Marc Feeley
feeley at iro.umontreal.ca
Sun Aug 16 08:45:06 EDT 2009
On 15-Aug-09, at 2:17 AM, FFT wrote:
> Some guy there is saying Gambit's GC may be slow. Someone might want
> to address that concern. I was impressed with Gambit's performance so
> far, but I don't really care about real-time and I don't know enough
> about the internals.
>
> http://www.reddit.com/r/programming/comments/9ad60/another_realworld_use_of_scheme_quantz_a_newly/c0c123q
Gambit's current GC is a hybrid stop-and-copy and mark-and-sweep. The
main characteristic for this discussion is that when there is a GC,
all currently allocated objects which might be reclaimed are checked
for reachability from the roots (in other words it is not a
generational garbage collector). A generational garbage collector
would have two (or more) types of GCs: minor GCs where a (small)
subset of the whole heap is scanned, and major GCs where all of the
heap is scanned.
Generational GCs have a higher cost for mutations, but the average GC
pause is lower. On the other hand, when there is a major GC, the GC
pause may be longer than for a nongenerational garbage collector. In
other words a nongenerational GC has more predictable GC pauses
(although on average they are longer), which is a good thing for real-
time applications like games (you wouldn't want your animation to run
smoothly in general, and every 5 seconds have a "frame skip"). Of
course the best situation would be to have a real-time garbage
collector, but QuantZ shows that it is not necessary for a real-time
game if you are careful how much and when you allocate.
Marc
More information about the Gambit-list
mailing list