Hi, I'm finally getting back to this (sorry for the delay!).
Han-Wen Nienhuys <[EMAIL PROTECTED]> 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. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
