[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