Re: Guile + Boehm GC: First Remarks

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:

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

I know, and that has been a real concern for me.

Interestingly, porting Guile to BGC has been one of these "idealistic"
goals for a number of years.  :-)

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

Note: this is an _experiment_, whose purpose is precisely to get a
better understanding of the feasibility of the migration, of the gains
from a user perspective, and of the performance implications.
Personally, I'm inclined to move to GBGC, _if_ the performance overhead
is acceptable, that is, if the maintainability and robustness gains
overweight the performance cost.  But (i) this is only my personal
opinion, and (ii) I don't have serious performance results at this time.
This clearly needs to be evaluated before we can consider BGC as an
option.

Also, when discussing performance, one has to keep in mind that it is
very unlikely that anybody will ever improve the performance of Guile's
GC (I did try, had to gave, and got motivated by BGC ;-)).  On the
contrary, GBGC is constantly being improved, and performance seems to be
the main focus of Hans currently.

BTW, I did not mean to be insulting about the current GC, but a GC
written in C (be it Guile's or Boehm's) is _not_ something easily
maintainable.

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

My feeling is that it does add value, but we need to weight the pros and
cons.

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

Exactly, that's the point I was trying to make.  If, for instance,
Bigloo's interpreter outperforms GBGC, then this means that there is
room for optimization in Guile's interpreter.  More generally, Guile-VM
(or some other form of compilation) is the way to go if we want to
noticeably improve performance.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel