On Mon, 4 Jun 2007, Ludovic Courtès wrote: > Hi, > > Kjetil Svalastog Matheussen writes: > >> [2] tla my-default-archive lcourtes@laas.fr--2006-libre >> tla get guile-core--boehm-gc > > So that's the one you've been using and referring to as "Guile + Boehm > GC"? Glad to hear it! ;-) > Sorry I didn't write that in my first mail. > Did you make sure to compile libgc "the right way", so that locking in > with a multi-threaded libgc doesn't hurt performance[0]? > I have tried with and without both --enable-threads=posix and --enable-parallel-mark. No difference, it seems to work perfectly anyway. > The main thing that needs to be done before we can consider this > solution now is to compare both memory usage _and_ execution time of the > two Guiles. Yes, but for some kinds of software, like programs with custom gui's, sound processing programs, interactive graphical programs, interactivety is exclusively more important than those two. I consider the freeze that the guile's built-in gc cause to be its biggest problem. In fact, I don't think execution time is an important factor here at all. Don't get me wrong, of course execution time is important in general, but a change in execution time of a gc benchmark program within the factor of two sounds like an insignificant difference compared to what is gained in interactivity. > For instance, with the default settings, Guile + Boehm GC is slightly > faster than Guile when running `gcbench.scm', but it might consume more > memory. This needs to be analyzed. Reports as to how this impacts SND > are also more than welcome, of course! ;-) > I'm going to run Guile + Boehm GC + SND for a while now and report back if anything unusual happens. I might even release a special version of SND with guile + the Boehm GC included to the public in the near future, because of the huge advantages it has. This might generate a lot of feedback. And if no one reports back, then its a good sign that it works well.