Re: Speed or functionality in Guile? (was: Re: gc notes available)

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

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

> Jim Blandy <jimb@red-bean.com> writes:
> 
> > > 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.)
> > 
> > This is the crux of the matter.
> > 
> > Which would people prefer?
> > 1) Guile becomes slower overall, but does not pause noticeable for GC.
> > 2) Guile becomes faster overall, and most GC pauses become
> >    unnoticable, but does still pause occsionally?
> > 
> > (Mikael, have I correctly represented the choice?)
> 
> Yes.

I don't think it has to or should be one or the other. The thing about
it is that the second will be dealt with first, unless there's someone
else out there who wants to work on an incremental gc right now; if
not, I'd give it a tackle after I finish what I'm doing now, but that
may take a while. I think, though, that the improved gc(s) that I'm
working on will probably benefit more people (particularly, me :) than
the incremental, and are also close enough to the current gc that I
can see easily where things get broken with the changes I've made
(this is a big win for me, because I don't know the in's and out's of
each bit of guile).

> > If a brave soul implements an interface that allows the user to choose
> > between the two, that's the best.  But I certainly won't discourage
> > other work while waiting for that.

I would expect that most uses would be to pick one or the other, and
run with it, so it's probably enough to make it selectable at
startup... since this will be necessary, anyway, it'll get done.  From
most user code, the gc shouldn't even be a factor... for apps that
need a certain gc, it will just require guile to be invoked as
something like guile -g i, or --garbage-collector=incremental, to
satisfy gnu options ;)
 
> I think Greg's work is really exciting.  Even if he comes up with a
> collector that has noticeable GC pauses, it is clearly a major step
> forward for Guile to get a generational GC.  (This is true even if the
> gengc is slower than the current gc for smaller applications because
> of the good scaling properties.)

Well, it has produced an absurd number of segfaults, and they're
pretty exciting ;) An improvement to the current gc is only a few days
from being ready for public testing (cross fingers), and I'm
optimistic about the speed improvements it will bring over the current
gc, particularly in the small program case. 

> But now, let's continue the discussion:
> 
> > Failing that, I think 2) is what most of the Guile community wants.
> 
> If the Guile community of the future will consist of people embedding
> Guile in their applications I think 1) is what many people want.
> 
> What we are weighing here is speed against functionality.
> 
> Even though I like it when programs are efficient, I don't think speed
> is the most important thing for an application extension language.
> But one thing I really would like to do in an extension language is to
> write my GUI in it.
> 
> If the GUI makes noticeable pauses for GC then the application won't
> be nice to use.  Applications should be nice to use.  Therefore,
> noticeable GC pauses excludes the use of Guile for writing GUI:s.
> 
> Slowing down Guile by, for example, 25% isn't a major drawback.

Well, let's not go nuts ;) (although, with the plummet prices of
hardware, we probably don't have to be too anal about performance, but
I'm not a big fan of the 'buy a new computer to run this software'
train of thought).
 
> Not being able to use Guile for GUI:s is a major drawback, because it
> excludes one area of use.
> 
> The debugging evaluator is 3 times slower than the SCM evaluator but
> it supplies backtraces.  This is another case where speed is weighed
> against functionality.  How often do people switch off the debugging
> evaluator to increase evaluation speed?  Myself, I almost never do it.
> 
> I realize that many users in the Guile community use Guile for batch
> type processing or scripts where GC pauses doesn't matter.  Actually,
> people writing GUI:s in Guile will probably be a minority.
> 
> But isn't GUI:s a legitimate use of Guile?
> 
> Should we support only the majority type of programs or should we try
> to cover a broader range?
> 

It's definately important to support all uses of guile. What I do want
is to see if the gc is going to be that big a factor when it's
implemented. If it is, we'll just need another gc to select :)


> Then, finally, a more technical point: If GC pauses are short enough
> they won't be noticeable, and it *will* be possible to have a "stable
> feeling" in a Guile GUI.  It might be argued that a generational GC
> leads to short enough pauses.  But note that this is true only if
> there isn't occasions where all generations are collected during the
> same pause, which is the common situation in generational garbage
> collectors.

Not strictly necessary, though. Even in the worst case, the frequency
of large collections can be tuned and scheduled by the program when it
knows it has free time... this is a bigger problem in the improvements
I'm currently working on with the mark and sweep, because it always
has to do a full scan, saving it's time in sweeping. This isn't as bad
as it initially sounds, as frugal sweeping and small segment sizes can
improve gc time tremendously, even with a full scan of live objects
(it's sort of a generational scheme, without an explicit generation
per object).


> This is one of the reasons why it may be a good thing to talk about
> these issues now.
> 
> /mdj
> 
> 

-- 
Greg