[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: state of Guile GC
From: |
Ludovic Courtès |
Subject: |
Re: state of Guile GC |
Date: |
Mon, 17 Sep 2007 22:56:01 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
Hi Julian,
"Julian Graham" <address@hidden> writes:
> I realize that a lot of this has to do with the allocation profile of
> my Scheme code, and I'm working on profiling it;
It's not only your fault: the evaluator conses every time a Scheme
procedure is invoked, including when invoked in tail position. That
ought to be fixed.
BTW, did you notice a significant change compared to your previous Guile
version? Were you actually using `scm_block_gc ()' before?
You might want to build a single-threaded Guile 1.8 if possible, which
should perform much better, although that is admittedly not very
convenient.
> * In 1.8, you guys removed scm_block_gc, and the comments in the
> Changelog seem to indicate that this was a requirement because of the
> way the redesigned GC interleaves itself with "Guile mode" C code.
> Would it really be impossible to re-add some way of (temporarily)
> disabling GC?
Sorry, I don't know what the rationale was, maybe others can help.
> * Any suggestions from application authors on how to control the
> behavior of the GC from C? dsmith on #guile suggested that there
> might be a way to trick Guile into thinking a GC wasn't necessary by
> flubbing the GC stats somehow, but I couldn't figure out a way to do
> that that looks portable.
Maybe the `GUILE_MIN_YIELD_{1,2}' environment variables can help, as I
noted in a recent post. Did you try playing with them?
But that's not really targeting the "application authors", rather the
end-user...
> * Out of curiosity, what are the technical / theoretical constraints
> that make Guile's GC perform the way it does? There are other
> garbage-collected languages with (what I would imagine are) much
> heavier allocation footprints (C#, Java) that seem to have much faster
> GC. (P'raps they collect in a separate thread?) Do other Schemes do
> things differently?
It's hard to tell whether it's really so inefficient (although looking
at the code gives the impression that there's room for
micro-optimizations).
> * What's the state of porting Guile to use Boehm GC? I was following
> Ludovic's research into it but things kind of trailed off about a year
> ago when he posted some rather unhappy performance information.
He. ;-)
Then there were happier pieces of information, namely about how `libgc'
has to be compiled to get better performance [0]. At this stage,
libgc-enabled Guile performs comparably to the current Guile. The thing
is: good performance measurements are needed, including an analysis of
the execution time/memory usage tradeoff. This has been on my TODO list
for a while now...
Also, it's been reported that libgc-Guile provides lower latency than
regular Guile in SND [1].
Hope this helps,
Ludovic.
[0]
http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/1516/
[1] http://thread.gmane.org/gmane.lisp.guile.devel/6624
- state of Guile GC, Julian Graham, 2007/09/17
- Re: state of Guile GC,
Ludovic Courtès <=