Re: Guile + Boehm GC: First Remarks

[Mikael Djurfeldt]

On 6/1/06, Ludovic Courtès <address@hidden> wrote:
> "Mikael Djurfeldt" <address@hidden> writes:
>
> > Yet, as long as the current GC is more efficient (as measured by
> > performance tests), there is no reason to switch, right?
>
> Well, it's still unclear whether the current GC is more efficient, and
> how much more if it is.  Furthermore, the GBGC code is a few weeks old
> so it may be possible to tune it a bit more.
>
> IMO, although I'm quite concerned with performance, I don't think it
> should be the only criterion: maintainability and portability are
> important as well.

Certainly.  It's just that Guile has, to some extent, and with the
exception of a recent restructuring of the GC, had this tradition of
sacrificing performance for all kinds of "idealistic" goals with the
promise of increased future efficiency, getting more and more sluggish
all the time.  (It was quite efficient originally.)

If BGC holds the promise of efficiency, it might be nice to achieve
this before throwing out the current GC which is, btw, not
unreasonably unmaintainable or unportable.

The only point I would like to make is that it is silly to care too
much of the amount of thinking which has gone into BGC and its broad
usage if, in fact, it doesn't add anything of real value to Guile.

> The fact that Bigloo uses BGC also tends to reassure
> me: if Guile can someday perform as bad as Bigloo compiled code (or
> simply, as bad as its interpreter), then I'll be very happy.  ;-)

But current sluggishness is not mainly due to the current GC.  In
fact, for a scheme interpreter there might be advantages of using a
customized solution. One thing which would boost performance
tremendously would be to integrate Keisuke's guile-wm code, or
something a la QScheme.


In any case, I'm impressed with your achievement and appreciate the
extent of the work required.  And I think it would be just great if
this can be proven to be a road to better efficiency.  I hope so!