Re: Comparing Guile's GC with BDW-GC
Hello, Han-Wen Nienhuys [EMAIL PROTECTED] writes: I wonder whether this is a useful benchmark. 1.54 mb is small compared to the 2mb L2 cache of a core duo. I think it's best to look at tests that exercise a larger working set. You're right. These are not GC benchmarks anyway, but I wanted to see how it compares with these applications. Thanks, Ludo'.
Re: Comparing Guile's GC with BDW-GC
Hi Neil, Neil Jerram [EMAIL PROTECTED] writes: On 05/11/2008, Ludovic Courtès [EMAIL PROTECTED] wrote: I finally [0] conducted experiments to compare Guile's GC with my port of Guile to the Boehm-Demers-Weiser GC (BDW-GC). The code for that port is not currently available on-line but I'd be happy to push it somewhere (would Guile's repo at Savannah be a good fit?). I don't see why not... An argument could be it's not exciting and it increases the repository size. :-) But if nobody says it, I'm happy to proceed. For `string', I expect it to be partly due to the fact that under unmodified Guile it's libc's malloc that's exercised more than the GC itself (since stringbuf contents are allocated with `malloc ()'). How is that different in BDW-GC Guile? (I was actually referring to execution time mainly.) In BDW-GC Guile, everything is allocated using the GC primitives (GC_malloc), and libc's `malloc ()' isn't used at all. Note that this doesn't explain the significantly larger heap of Guile compared to BDW-GC. One explanation could be incorrect stats that lead Guile's GC to think there's plenty of heap available. It's always possible to trade execution for heap, isn't it? For example, I presume we could configure current Guile so as to gc less? I presume so, but I don't know exactly how: there are too many (environment) variables to be tweaked, and their effect on heap usage or execution time is not obvious (see, e.g., http://thread.gmane.org/gmane.lisp.guile.devel/6699/focus=6836). I forgot to mention that FSD = 3 and non-incremental mode is the default for BDW-GC. In these results, it looks like Guile is quicker for a given heap size - or smaller for a given execution time. Well, the benchmarks only show that Guile by default is slower and uses less heap than BDW-GC, so you're jumping to the conclusions. It should be noted that this series of benchmarks does not particularly stress the GC and uses a small heap (less than 2 MiB, except for `guile-test'), unlike `gcbench' and `string'. I noticed that Will Clinger et al. collected GC benchmarks at http://www.ccs.neu.edu/home/will/GC/sourcecode.html . I'll run a series of measurements with these. Do you just mean having to maintain the code? I'll write a separate note for that. Thanks! Ludo'.
Re: Comparing Guile's GC with BDW-GC
Ludovic Courtès escreveu: Hello! heap size (MiB) execution time (s.) Guile1.54 (1.00x) 6.316 (1.00x) BDW-GC, FSD=32.41 (1.57x) 4.943 (0.78x) I wonder whether this is a useful benchmark. 1.54 mb is small compared to the 2mb L2 cache of a core duo. I think it's best to look at tests that exercise a larger working set. From casual inspection of the numbers, I'd say that going to BDW is worth it: the speed/memory usage is roughly comparable, and the ability to junk 6k lines of hairy code is definitely worth it. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: Comparing Guile's GC with BDW-GC
Ludovic Courtès escreveu: Hello! I finally [0] conducted experiments to compare Guile's GC with my port of Guile to the Boehm-Demers-Weiser GC (BDW-GC). The code for that port is not currently available on-line but I'd be happy to push it somewhere (would Guile's repo at Savannah be a good fit?). I recommend you push a branch to savannah, for everyone to see what is happening. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: Comparing Guile's GC with BDW-GC
On 05/11/2008, Ludovic Courtès [EMAIL PROTECTED] wrote: Hello! I finally [0] conducted experiments to compare Guile's GC with my port of Guile to the Boehm-Demers-Weiser GC (BDW-GC). The code for that port is not currently available on-line but I'd be happy to push it somewhere (would Guile's repo at Savannah be a good fit?). I don't see why not... Just a couple of quick comments on the results... The Results --- There are two benchmarks where BDW-GC is both faster and less memory-hungry than Guile's GC (marked with an `!'): For `string', I expect it to be partly due to the fact that under unmodified Guile it's libc's malloc that's exercised more than the GC itself (since stringbuf contents are allocated with `malloc ()'). How is that different in BDW-GC Guile? In most other cases, BDW-GC yields smaller execution times at the expense of increased heap usage. It's always possible to trade execution for heap, isn't it? For example, I presume we could configure current Guile so as to gc less? In these results, it looks like Guile is quicker for a given heap size - or smaller for a given execution time. I think the question of whether BDW-GC is worth it becomes more of an engineering matter if performance is neither problematic not exceptional. Do you just mean having to maintain the code? Regards, Neil
