This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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.

> 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 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.)

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.

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?


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.

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

/mdj