[gambit-list] Interactive 3D graphics with Gambit-C

Marc Feeley feeley at iro.umontreal.ca
Tue Sep 23 16:44:07 EDT 2008


I agree with Brad.  In fact some people are writing commercial video  
games right now with Gambit and the GC is performing reasonably well.   
This does not mean that a better (real-time or generational) GC  
wouldn't be good to have when the memory requirements are more severe,  
but with some planing and profiling it is possible to get the current  
GC to perform at a near real-time performance standard.

Marc


On 23-Sep-08, at 1:14 PM, Bradley Lucier wrote:

>
> On Sep 23, 2008, at 2:32 PM, David St-Hilaire wrote:
>
>>
>> Alex Sandro Queiroz e Silva wrote:
>>> Hallo,
>>>
>>>    I am thinking about doing some basic 3D graphics with Gambit-C.
>>> Although I am sure code generated by Gambit-C is fast enough[1], I
>>> am a
>>> bit worried about the garbage collector. What's the type of garbage
>>> collector used by Gambit? If it kicks in during interactive
>>> rendering,
>>> should I expect annoying pauses?
>>>
>>
>> Unfortunately, yes you should expect such problems. If I'm correct,
>> gambit's gc
>> is a regular stop & copy style collector, which stops the world at
>> each gc. I
>> think that Marc has changing this to either a generationnal or
>> incremental gc,
>> which would lead respectively to smaller collection pauses or
>> virtually none
>> (but maybe with execution speed reduced?).
>>
>> Still, if you pre-allocate lots of space, gc shouldn't occur too
>> often and you
>> can always force a gc with (##gc) at opportune moments.
>
> GCs are often very short, on the order of milliseconds, for example on
> a 2.0GHz G5:
>
> [descartes:~/Desktop] lucier% gsi
> Gambit v4.2.8
>
>> (##gc-report-set! #t)
>> (define a (time (expt 3 10000000)))
> *** GC: 1 ms, 692K alloc, 386K heap, 82.0K live (21% 65712+18208)
> *** GC: 1 ms, 992K alloc, 386K heap, 88.0K live (23% 71920+18208)
> *** GC: 1 ms, 1.19M alloc, 1.27M heap, 94.8K live (7% 55584+41536)
> *** GC: 2 ms, 2.08M alloc, 2.22M heap, 163K live (7% 55456+111184)
> *** GC: 2 ms, 3.22M alloc, 4.05M heap, 253K live (6% 55392+204064)
> *** GC: 2 ms, 5.48M alloc, 6.86M heap, 435K live (6% 55328+389808)
> *** GC: 4 ms, 9.98M alloc, 14.2M heap, 797K live (5% 55264+761280)
> *** GC: 7 ms, 19.0M alloc, 27.2M heap, 1.49M live (5% 55200+1504224)
> *** GC: 12 ms, 36.9M alloc, 54.0M heap, 2.90M live (5% 55136+2990128)
> (time (expt 3 10000000))
>     1165 ms real time
>     1096 ms cpu time (936 user, 160 system)
>     9 collections accounting for 33 ms real time (9 user, 23 system)
>     71837896 bytes allocated
>     no minor faults
>     no major faults
>
> I'd write the app without worrying about gc times, instrument it with
> ##gc-report-set!, and then worry about gc's if they become a problem.
>
> Brad
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list