Re: gc notes available

[Greg Harvey <Greg.Harvey@thezone.net>]

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

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > Mikael Djurfeldt <mdj@nada.kth.se> writes:
> > 
> > > Should I really need to do all dynamic GUI stuff in C code?
> > 
> > Definately not. But, is it going to be generating that much garbage
> > that the gc will be invoked so many times as to slow the thing down
> > noticably?>
> > [...]
> > This is a desire for very short, unnoticable pauses, and that's the
> > goal anyway.
> 
> If I can't notice the GC pauses in the behaviour of the GUI, then
> *I'm* happy (although I can imagine that better-than-human realtime
> performance could be wished by other types of applications).

The problem here is that that it's not really something you can expect
from a scheme interpreter running on a generic os, anyway. Hard
realtime is quite aptly named :), and needs to have total control at
the scheduling level (maybe a port to rtlinux?). 

 
> But I have one additional wish (I haven't yet had time to read your
> text, so I don't know if you address this problem): When Guile
> switches to real threading (POSIX threads) we'll have to stop all
> threads, using mutices, before GC with the current collector.  

I've been thinking about this. The generational scheme that I'm
working on now is using memory protection, so it could be able to keep
well behaved threads going, since the sweep phase doesn't need to
modify the heap. A thread that tries to allocate or modify certain
parts of the heap will be stopped, but the 'draw Mr. Doodle, scooting
about on a skateboard' kind of things should be able to keep
going. Actually, things do get a bit more complex because the stack of
these threads can continue to grow (and this is an issue in
incremental as well), so it may make the most sense to just say 'stop
it for a second!', unless the thread can guarantee it's going to play
nice (a bit more work for multi-threaded apps, but they have more to
do anyway >:-P).

 
> > > May I ask: How important is *performance* in a scripting language?
> > 
> > Important, but not the most vital bit in most uses. The main benefit
> > to a scripting language is the programming time it saves.
> > [...]
> 
> Exactly.  This is what I meant when I wrote the question.  (But it
> seems to me that both you and thi interpreted it differently.  The
> last lines of my letter was supposed to mean: Slowing down Guile a
> little may be worth the cost if it makes Guile useful for new classes
> of tasks, like those dependent upon realtime performance.)
> 
> > It doesn't matter to me whether it takes 5 ms or 5 seconds to start
> > up
> 
> (This is really a different issue than the one we discuss above.)
> I don't agree.  While performance may not be the most important thing
> in a scripting language it is extremely important that it doesn't take
> 5 s to start up.  I want to write Guile scripts to use as tools
> from the command line.  That kind of scripts has do startup swiftly.
> I would get crazy if commands like `ls' and `cd' took 5 s to start.

Obviously, you don't want interactive programs to start that slowly,
but for automated tasks (which is what I had in mind here) it's not a
big deal... the computer isn't standing around, tapping on it's watch
:) The start up time of guile should become negligable in the not too
distant future, so even these should be feasible.

I think, though, that guile's niche in the scripting world is similar
to python's, in that it's probably never going to beat perl in a race
through a bunch of strings (and it certainly isn't worth sacrificing
their cleanness to do it), but they are both robust enough to make
writing and maintaining large scripts a sensible and pleasant thing
(unlike perl, where a large script [like my connect script :(]that's
been lying around for a few months could cause you to go cross-eyed
and insane trying to fix it).

 
> Many of my bourne shell scripts are tools on the same level.  An
> example of the kind of scripts I'm referring to is a "module" command
> which I've written in Guile.  I use it to switch between different
> versions of packages by altering environment variables like PATH,
> LD_LIBRARY_PATH etc.
>
> But I don't think we have to worry much longer about start up time in
> Guile.  Gary is rewriting I/O---that will be a big boost.  Eventually,
> when we get the new module system and have had time to do a bit of
> restructuring, startup time will be acceptable.

And, of course, a gengc :) 

-- 
Greg, getting a real hang of shameless plugs ;)