[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile + Boehm GC

From: Ludovic Courtès
Subject: Re: Guile + Boehm GC
Date: Tue, 21 Mar 2006 18:23:15 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Hi Han-Wen,

address@hidden (Han-Wen Nienhuys) writes:

> it's here,
> note that this is a patch for the "old" GC code, before I took a stab
> at rewriting.

The good news is that it looks quite simple!  The main changes are
located here (diffstat):

 libguile/gc.c                 |  854 +-----------------------------------------
 libguile/gc.h                 |   57 --

However, it looks like you didn't look at weak hash tables back then.
My impression is that porting them would be the most difficult task.

> It was a quick hack, and performance was a little worse, but I think
> it could be just as performant as GGC. Note that many interpreters
> (eg. MzScheme) use BGC by default.  Also, measuring performance of GC
> is hard, since there is a space/time tradeoff, so you should really
> measure the tradeoff, something I haven't done.

Yes.  But GGC's performance is terrible IMO (see my posts a few months
ago), and also GGC is used only within Guile.  So I'm confident that BGC
may work better, and even if it doesn't, chances are that it may improve
over time given the number of users it has had.

> I think it would be good to move to BGC. BGC is used by many other
> interpreters, and receives more attention wrt performance and
> bugfixing than GGC. Dropping code is almost always good


> BTW, I ran across Judy trees today,
> would it be worthwhile to try replacing resizing hash tables in Guile
> with Judy trees? I expect that it would incur a significant speedup.

I was not aware of this project but I'm not so sure it would have a
significant impact.  Currently, Guile spends a huge amount of time
managing memory and improving this should be priority #1 I think.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]