From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) Newsgroups: gmane.lisp.guile.devel Subject: Re: GC improvements Date: Fri, 6 Jan 2006 20:22:24 +0000 (UTC) Organization: LilyPond development Message-ID: References: <87slsnk9u0.fsf@laas.fr> <43BB1EDF.7080404@xs4all.nl> <87oe2snf01.fsf@laas.fr> <87psn64tq5.fsf@laas.fr> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1136578997 10752 80.91.229.2 (6 Jan 2006 20:23:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2006 20:23:17 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 06 21:23:15 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Euy73-00052n-Uc for guile-devel@m.gmane.org; Fri, 06 Jan 2006 21:23:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Euy8r-0006eh-4r for guile-devel@m.gmane.org; Fri, 06 Jan 2006 15:24:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Euy8i-0006bn-D6 for guile-devel@gnu.org; Fri, 06 Jan 2006 15:24:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Euy8f-0006a4-EG for guile-devel@gnu.org; Fri, 06 Jan 2006 15:24:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Euy8e-0006Zj-7v for guile-devel@gnu.org; Fri, 06 Jan 2006 15:24:40 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1EuyAS-000427-42 for guile-devel@gnu.org; Fri, 06 Jan 2006 15:26:32 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Euy6g-0004yg-Kv for guile-devel@gnu.org; Fri, 06 Jan 2006 21:22:38 +0100 Original-Received: from muurbloem.xs4all.nl ([213.84.26.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 21:22:38 +0100 Original-Received: from hanwen by muurbloem.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 21:22:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: guile-devel@gnu.org Original-Lines: 37 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: muurbloem.xs4all.nl X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5580 Archived-At: In article <87psn64tq5.fsf@laas.fr>, Ludovic Courtès wrote: >> This interleaving of initialization and sweeping makes it pretty hard to >> track exactly where fresh cells come from. I guess one solution might >> be to maintain a list of the uninitialized segments and pick cells >> directly from there before actually sweeping. >* This poor man's generational GC has the advantage of being quite easy > to implement. Basically, instead of having a single segment table as > we have now, we'd have to maintain a set of three segment tables, > which would not be too complicated it seems. > > In particular, it's much easier to implement than the per-cell > generational GC, as proposed by Greg Harvey in > http://home.thezone.net/~gharvey/guile/ggc-notes.txt . It's also less > intrusive: basically `scm_i_sweep_some_segments ()' is the only place > where generations would be taken into account. Of course, the outcome > would certainly be better with a per-cell approach, but I'd expect the > per-segment approach to yield a non-null benefit for a pretty low > cost. I don't get it. I thought the generational would save on the marking phase. What's sweeping got to do with it? >What do you think? Are there flaws in this reasoning? :-) Yes; it's reasoning. In my experience, nice sounding theories and approaches are usually meaningless. Programmers (including myself) are notoriously bad at predicting performance characteristics. Why don't you do some measurements before trying to design code? I've tried "poor man's" optimizations before, and I always had to conclude that optimizations introduced extra overhead, with a net loss in performance. that If you want to have generational GC, I recommend to plug in Boehms GC collector. MzScheme also does this with good results. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel