unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
To: guile-user@gnu.org
Cc: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
Subject: Re: the future of Guile
Date: Tue, 4 Dec 2007 23:30:48 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0712042308590.21986@ttleush> (raw)
In-Reply-To: <1196798803.5494.26.camel@localhost.localdomain>



On Tue, 4 Dec 2007, Roland Orre wrote:

> On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
> ...
>> Oh, and another thing. My tests (available in the guile-devel archives)
>> also showed that the HBGC version usually use a bit less memory
>> than Guile's old garbage collector. (Yet another "should"
>> for replacing. :-) )
>
> I don't have much experience with different GC algorithms, but
> as I understand the HBGC is not intended for background GC.
>

Actually, it does:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html



> If the GC should be replaced I would consider it wise to
> replace it with an algorithm than can be run in a thread.
> This I consider strongly motivated by the fact that most new
> machines today are multi core. An efficient way to decrease the
> latency of the GC is to simply run it in background.
>

Sure, that would be great. But I don't think you know how hard
it is to actually do that... But as a matter of fact, the HBGC do
at least support parallell marking though, and I also think the
HBGC patch for guile supports that feature.



> Regarding GC I also think it is could be useful to have a GC that
> can compact the memory

I think the HB gc does a pretty good job of not fragmenting the memory
at least.



> and of course give allocated memory back to
> the OS when no longer needed.

Well, Don't think you need that feature very often when using an OS 
supporting virtual memory.


Anyway, there is no third option here. The two choices are Guile's 
own garbage collector and Hans Boehms general garbage collector.
The last one is used in a bunch of other programming languages with great 
success, and except for being a bit slower on uniprocessor machines
when running a garbage collector benchmark, the HBGC seems
to generally work better for Guile than Guile's own GC.

Personally I hope the Guile developers choose to switch to HBGC when 
starting the next development cycle of Guile.



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


  parent reply	other threads:[~2007-12-04 22:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cmu-lmtpd-7104-1196779864-1@mail-imap2.uio.no>
2007-12-04 18:08 ` the future of Guile Kjetil S. Matheussen
2007-12-04 18:34   ` Kjetil S. Matheussen
2007-12-04 20:06     ` Roland Orre
2007-12-04 20:42       ` Ludovic Courtès
2007-12-04 22:30       ` Kjetil S. Matheussen [this message]
     [not found] <cmu-lmtpd-4316-1197047238-3@mail-imap2.uio.no>
2007-12-07 17:42 ` Kjetil S. Matheussen
2007-12-07  6:28 Marco Maggi
     [not found] <cmu-lmtpd-27643-1196871540-1@mail-imap2.uio.no>
2007-12-06 14:52 ` Kjetil S. Matheussen
  -- strict thread matches above, loose matches on Subject: below --
2007-12-05 22:32 Marco Maggi
2007-12-05 22:56 ` Ludovic Courtès
2007-12-05 21:02 Marco Maggi
2007-12-05 15:40 Mike Gran
2007-12-05 16:05 ` Julian Graham
2007-12-05 16:18 ` Daniel Ridge
2007-12-05 20:41 ` Ludovic Courtès
2007-12-05  9:01 Marco Maggi
2007-12-05 14:19 ` Roland Orre
2007-12-05 20:28 ` Ludovic Courtès
     [not found] <34.F3.20110.D6985574@avas19>
2007-12-04 19:54 ` the future of guile Daniel Llorens del Río
     [not found] <F8.1B.18780.B4965574@avas11>
2007-12-04 15:55 ` Daniel Llorens del Río
2007-12-04  6:50 the future of Guile Marco Maggi
2007-12-04  8:48 ` Stephen Compall
2007-12-04 12:41 ` Ludovic Courtès
2007-12-04 14:50   ` Bill Schottstaedt
2007-12-04 15:30     ` Ludovic Courtès
2007-12-04 23:00 ` Neil Jerram
2007-12-05 23:11 ` Andy Wingo
2007-12-06 19:48 ` Mikael Djurfeldt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0712042308590.21986@ttleush \
    --to=k.s.matheussen@notam02.no \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).