[plt-scheme] Some thoughts about GC and realtime aplications

On Fri, May 19, 2006 at 11:23:41AM -0700, John Clements wrote:
> 
> On May 19, 2006, at 11:09 AM, Ivan Boulanov wrote:
> 
> >Thank you for all your answers. You gave me very interesting  
> >information and I wonder why all these references have not been yet  
> >included to Scheme Wiki. It is a very, very interesting things  
> >especially for a little (beginner) schemer.
> >
> >Joe Marshall wrote:
> >>3.  Modern computers have *lots* of RAM.
> >If we treat such a techinical things relatively, we come to  
> >conclusion that there is no relative advantage for modern PCs over  
> >ancient ones. The more RAM amount and CPU time we get, the more we  
> >waste. It is a banality. The question is how competitive would be a  
> >game with GC to those that use manual memory management? Modern big  
> >games (The Elder Scrolls III, Doom 3 etc.) have a very strong  
> >demands on how fast resources have to be allocated and how fast  
> >have to be freed. Modern games can not allow to waste a huge amount  
> >of RAM just because GC techique requires this. I think there really  
> >have to be a hybrid high-performance approach. I should consult the  
> >given references.
> 
> One mistake here: don't confuse "uses lots of ram" with "runs  
> slowly".  In fact, the _opposite_ can be true; that is, in a gc  
> system you may be trading compactness for speed.  If I have lots of  
> ram, then I don't need to spend all my time making sure I don't  
> overflow a tiny little box.  To use a possibly inappropriate  
> metaphor, a factory with lots of floor-space will probably produce  
> things _faster_ than one that has a tiny footprint, because the extra  
> space allows the factory to optimize processes by taking more space.
> 
> 
> >And also you wrote:
> >>>A completely different approach is to use reference-counting  
> >>>instead of GC.
> >>>This approach is similar to the modern C++ programming approach  
> >>>of smart
> >>>pointers.
> >>
> >>This, I think, is the wrong approach.  If you trace a program that
> >>uses reference
> >>counts, you'll notice that it spends a good chunk of time  
> >>incrementing and
> >>decrementing the refcounters.  This is spread rather evenly  
> >>throughout the
> >>program, so it doesn't introduce noticable pauses, but it does  
> >>take up processor
> >>time.
> >I don`t really believe in that because I use smart pointers (read  
> >as "reference counting") everywhere I can and there is only a  
> >negligible overhead over raw pointers. Maybe I miss something?
> 
> Both argument and counterargument here are in need of support; surely  
> there's lots of work on the time taken by reference-counting in  
> various programs?
> 
> John
> 

My experience is that, if I manually do the reference counting, the overhead is 
quite low, and the debugging is quite hard.  But if I have some automated 
process to do them, many many more reference-count operations are generated than 
I would do by hand, but debugging is easy.

Manually, I don't increment and decrement for each temporary copy of a pointer 
the compiler chooses to make.  I don't even know what temporaries the 
compiler makes! Manually, I leave entire swaths of code uncounted, because I 
know they are manipulating objects that have pointers to them from elsewhere, 
and will therefore be preserved anyway.

-- hendrik

> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme