[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile + Boehm GC: First Remarks
From: |
Ludovic Courtès |
Subject: |
Re: Guile + Boehm GC: First Remarks |
Date: |
Sun, 26 Nov 2006 19:48:20 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi,
I'm finally getting back to this (sorry for the delay!).
Han-Wen Nienhuys <address@hidden> writes:
> I've patched it a bit to use GC_typed alloc for tagged data. It
> probably doesn't make much of a difference, since 90% of the data is
> regular cells, but see
> http://www.xs4all.nl/~hanwen/public/software/guile-bgc.patch
>
> With the tree benchmark (included in patch, I get 54 secs (Guile 1.8)
> vs. 1:25 (typed BGC). I forgot to measure regular BGC, though.
Thanks for the patch. I tried it out but it doesn't apparently yield
any performance improvement (see below).
> Note that BGC has ALL_INTERIOR_POINTERS switched on by default
> nowadays, which means that it may scan too much. You could try
> switching that off.
Good idea. I tried this (patch available in my Arch branch) and it does
indeed yield a slight improvement. Here's the summary of the various
performance measurements, each time running the whole `gcbench.scm' that
you provided:
* Guile 1.8 52 sec. (+0%)
* GBGC w/ tagged allocs 1"27 (+40%)
* GBGC w/o tagged allocs 1"18 (+33%)
* GBGC + no interior pointers 1"13 (+29%)
* GBGC + no interior ptrs + `GC_expand_hp' 1"13 (+29%)
In the last case, `GC_expand_hp ()' is systematically used to increase
the initial heap size at startup time; this may have a positive impact
on short-lived programs, but doesn't have any impact here,
understandably.
I guess we need other bright ideas. ;-)
Thanks,
Ludovic.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Guile + Boehm GC: First Remarks,
Ludovic Courtès <=