Re: gc notes available

[hjstein@bfr.co.il (Harvey J. Stein)]

Mikael Djurfeldt <mdj@nada.kth.se> writes:

 > hjstein@bfr.co.il (Harvey J. Stein) writes:
 > > 3. Emacs has a non generational GC that's on the slow side.  Does its
 > >    pauses cause a significant degradation of it's UI?
 > 
 > I don't think this is a fair comparison since you are less sensitive
 > to short pauses in a keyboard/text-based application such as Emacs.
 > Responsiveness is more important in a GUI.  It needs to have a "stable
 > feeling".
 > 
 > (But before I got my Ultra machine I *was* disturbed a lot even in
 >  Emacs precisely because of irregular delays of response.)

Short pauses while you're typing can really suck if they're too
frequent.

 > > 4. I wrote a tetris game for STk.  It has a non generational
 > >    conservative GC.  The pauses are unnoticable because I increased
 > >    the heap allocation at the beginning & call gc at times when it
 > >    won't be noticable to the user.
 > 
 > Well, what can I say.  I have a GUI for my simulator written in Guile
 > and it doesn't feel nice to interact with due to the irregular short
 > pauses.  But then I didn't change heap allocation or call gc.

How are you doing the GUI?  Using the guile interface to GTk?  Is it
basically an animation sort of issue - you want things to move
smoothly around the screen & gc interrupts it?  If that's the case
then I'd think what you'd need is:

 1. a generational collector tuned so it quickly gets to the point of
    never scanning your code, and
 2. tuning your code for minimal garbage creation.

You could test hypothesis 1 by compiling all your scheme code with
hobbit & linking it in.  Then gc won't have to keep scanning it.  See
how the behavior is then.  Maybe the rest of your code doesn't even
generate so much garbage & that'll be enough.  For that matter, if
you're really not so concerned about efficiency, then you could just
call (gc) after every timestep & everything would become perfectly
smooth - slow, but smooth.

 > I'm a little bit afraid of relying on such things because I imagine
 > that there are situations where it is hard to avoid GC even with these
 > measures.  I also would prefer not to have to think of these kind of
 > things when writing scripts in Guile.  GC is supposed to relieve the
 > user from thoughts about memory resources.  I would like to be
 > relieved from thinking about GC as well.  Finally, such measures
 > (calling GC at the dynamically right places) could have a bad
 > influence on program structure.

It's not & it doesn't.  It relieves the user from memory management,
preventing the class of bugs associated with pointer manipulations,
but he still has to worry about memory usage.  Excessive usage will
always yield bad performance.  You can't get away from thinking about
memory.  Furthermore, once you start loading in C code you have to
think about memory much more to make it work with gc.  But, at least
you don't have to explicitly track the lifetime of all your objects to
be able to free them by hand.

How can a few (gc) calls in the code have a bad influence on program
structure?  I think that's overblown.

 > > 6. How often do you have to wait for programs to do things in general?
 > >    I often have to wait for netscape, make, gcc, ... and none of them
 > >    have gc.  Why is waiting for gc a big deal, but waiting for DNS
 > >    resolution, or page formatting, or anything else acceptable?
 > 
 > I haven't claimed that waiting for GC is a big deal in general.  I
 > claim that it is a big deal when you're writing GUI code in Scheme.

I'd contend it's not GUI code, but animation.

 > > You stated that if the gc always scans all of memory then the gc
 > > pauses can be long, and if the gc pauses are long then it's bad for
 > > the GUI.
 > > 
 > > The real issue is *how* big, *how* long, and *how* bad.
 > 
 > Agreed.  I want a behaviour "smooth" enough not to have to worry about
 > GC when writing GUI:s.

The only way you'll get this is with a gc running in a separate thread.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il