Hi,
"Kjetil S. Matheussen" <[EMAIL PROTECTED]> writes:
> and for guile I think you use -rpath? :
Yes.
> No. But I have ran a series of benchmarks now:
Thanks for doing this!
To sum up, BGC is always slower but usually more memory-efficient than
GGC.
In Guile + libgc, you could try adding:
On Mon, 4 Jun 2007, Kjetil S. Matheussen wrote:
(benchmark 20) in Guile:
Guile: 4.4mb / 277s / 149mb
Boehm: 4.4mb / 243s / 148mb
Unfortunately, that one was probably wrong. Here is the retest result with
the Boehm GC guile:
Boehm: 5.2mb / 380s / 164mb
___
On Mon, 4 Jun 2007, Ludovic Courtès wrote:
Hi,
"Kjetil S. Matheussen" <[EMAIL PROTECTED]> writes:
libgc (v6.8) was compiled with the --enable-threads=posix only.
So `THREAD_LOCAL_ALLOC' was defined in your libgc build, right?
Yes: -DTHREAD_LOCAL_ALLOC=1
Running the benchmark program
Hi,
"Kjetil S. Matheussen" <[EMAIL PROTECTED]> writes:
> libgc (v6.8) was compiled with the --enable-threads=posix only.
So `THREAD_LOCAL_ALLOC' was defined in your libgc build, right?
> Running the benchmark program directly in guile gives no
> difference. Both spent about 50 seconds running t
On Mon, 4 Jun 2007, Ludovic Courtès wrote:
Actually, I haven't used guile for other interactive stuff than
snd. And snd is huge. It could be that the boehm gc works a lot lot
better for really large programs than guile's gc. I'll try to run the
gc benchmark program inside snd (with lots of sch
uess a "large fraction" of Guile users will be even more
concerned about memory consumption and execution time.
> 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
On Mon, 4 Jun 2007, Kjetil S. Matheussen wrote:
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 prog
On Mon, 4 Jun 2007, Ludovic Courtès wrote:
Hi,
Kjetil Svalastog Matheussen <[EMAIL PROTECTED]> writes:
[2] tla my-default-archive [EMAIL PROTECTED]
tla get guile-core--boehm-gc
So that's the one you've been using and referring to as "Guile + Boehm
GC"? Glad
Hi,
Kjetil Svalastog Matheussen <[EMAIL PROTECTED]> writes:
> [2] tla my-default-archive [EMAIL PROTECTED]
> 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! ;-)
Did you make sure
On Sun, 3 Jun 2007, Kjetil Svalastog Matheussen wrote:
>
>
> On Sun, 3 Jun 2007, Kjetil Svalastog Matheussen wrote:
>
> >
> >
> > (CC guile-dev)
> >
> >
> > On Sun, 3 Jun 2007, Bill Schottstaedt wrote:
> >
> > > Thanks! I'll merge your changes into my versions this morning.
> > > I saw
On Sun, 3 Jun 2007, Kjetil Svalastog Matheussen wrote:
>
>
> (CC guile-dev)
>
>
> On Sun, 3 Jun 2007, Bill Schottstaedt wrote:
>
> > Thanks! I'll merge your changes into my versions this morning.
> > I saw some discussion about the Boehm GC, but I didn't try it --
> > let me know how it go
x27;m thinking about releasing a new version of snd-ls with embedded guile +
boehm gc patch. It'll be a monster package, but snd feels so nice now that
I might do it.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
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/~hanw
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Yes, `autogen.sh' makes a lot of assumptions about what your file system
> should contain. Personally, I no longer use it: I use the more reliable
> (and less intrusive) `autoreconf -i'.
>
> I think we should either remove that script or simply have i
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès schreef:
>> $ tla register-archive http://www.laas.fr/~lcourtes/software/arch-2005/
>> $ tla get [EMAIL PROTECTED]/guile-core--boehm-gc--1.9
>
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall
> -Wmissing-prototypes -
Hi Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Just a note: autogen.sh barfs while trying to generate BUGS.
> apparently
>
> ../guile-scripts
>
> doesn't live where it is assumed to live.
Yes, `autogen.sh' makes a lot of assumptions about what your file system
should contain. Perso
Ludovic Courtès schreef:
Well, no real news. My "not-so-meaningful benchmarks" (running a
loop[*]) reproductively show that "GBGC" is noticeably slower than "real
Guile" (1.5 to 2 times slower).
with some final tweaks I got it to 26% (large test) and 32% (small test)
slower.
--
Han-Wen Nie
Ludovic Courtès schreef:
Well, no real news. My "not-so-meaningful benchmarks" (running a
loop[*]) reproductively show that "GBGC" is noticeably slower than "real
Guile" (1.5 to 2 times slower).
the following options turn on generational GC
GC_enable_incremental ();
GC_time_limit = GC_TIM
Ludovic Courtès schreef:
Hi Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
Ludovic Courtès schreef:
But please, relax about performance, we still haven't run any meaningful
benchmark. ;-)
btw, is there any news on this patch? I'm quite keen on dumping
LilyPond's Rational class in fa
Ludovic Courtès schreef:
But please, relax about performance, we still haven't run any meaningful
benchmark. ;-)
btw, is there any news on this patch? I'm quite keen on dumping
LilyPond's Rational class in favor of Scheme rationals, but adding gc
mark functions for that is just too much work;
Ludovic Courtès schreef:
But please, relax about performance, we still haven't run any meaningful
benchmark. ;-)
btw, is there any news on this patch? I'm quite keen on dumping
LilyPond's Rational class in favor of Scheme rationals, but adding gc
mark functions for that is just too much work;
Ludovic Courtès schreef:
$ tla register-archive http://www.laas.fr/~lcourtes/software/arch-2005/
$ tla get [EMAIL PROTECTED]/guile-core--boehm-gc--1.9
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall
-Wmissing-prototypes -Werror -MT libguile_la-gc.lo -MD -MP -MF
.deps/libguile_la-
Ludovic Courtès schreef:
I recently merged in changes from HEAD in my BGC branch. If you want to
give it a try and if you want to help, you can fetch it this way:
$ tla register-archive http://www.laas.fr/~lcourtes/software/arch-2005/
$ tla get [EMAIL PROTECTED]/guile-core--boehm-gc--1.9
Hi Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès schreef:
>>
>> But please, relax about performance, we still haven't run any meaningful
>> benchmark. ;-)
>
> btw, is there any news on this patch? I'm quite keen on dumping
> LilyPond's Rational class in favor of Scheme
Ludovic Courtès schreef:
But please, relax about performance, we still haven't run any meaningful
benchmark. ;-)
btw, is there any news on this patch? I'm quite keen on dumping
LilyPond's Rational class in favor of Scheme rationals, but adding gc
mark functions for that is just too much wo
On Wed, 2006-05-31 at 10:49 +0200, Ludovic Courtès wrote:
> You can get it from my Arch archive:
>
> $ tla register-archive http://www.laas.fr/~lcourtes/software/arch-2005
> $ tla get -A [EMAIL PROTECTED] guile-core--boehm-gc--1.9 \
> guile-core--bgc
>
> A tarball and a diff against c
In article <[EMAIL PROTECTED]>,
Mikael Djurfeldt <[EMAIL PROTECTED]> wrote:
>> I believe we would never have sufficient manpower to compete with it
>> (and it seems that most other language runtime implementors arrived to
>> the same conclusion).
>
>Yet, as long as the current GC is more efficient
On 6/1/06, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
Yeah, and it's actively maintained and actively used. The mailing list
is active as well and Hans Boehm has been very helpful answering my
questions. Also, it's ported to a wide range of platforms, it's highly
tuned, it's designed to live wi
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> unless otherwise specified, every register and every piece of memory
>> is scanned for pointers, not only the heap (however, only heap
>> regions allocated via the GC allocation routines are scanned).
>
On 6/2/06, Neil Jerram <[EMAIL PROTECTED]> wrote:
Perhaps we aren't yet running a truly representative set of benchmarks
though?
One should try to run some larger application with a large set of
slowly changing data structures, where the benefits of a generational
collector gets a chance to shi
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> unless otherwise specified, every register and every piece of memory
> is scanned for pointers, not only the heap (however, only heap
> regions allocated via the GC allocation routines are scanned).
I wonder if this is the main cause of BGC not perfor
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> Boehm is generational, AFAIK.
>
> Virtually everyone uses BGC. GCJ, MzScheme, BigLoog, GNU Obj-C, etc.
>
> See,
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>
> for a longer list.
Thanks; lots of interesting stuff there.
> By using BGC, you pot
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Also, when discussing performance, one has to keep in mind that it is
> very unlikely that anybody will ever improve the performance of Guile's
> GC (I did try, had to gave, and got motivated by BGC ;-)).
This should read
Hi,
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> Certainly. It's just that Guile has, to some extent, and with the
> exception of a recent restructuring of the GC, had this tradition of
> sacrificing performance for all kinds of "idealistic" goals with the
> promise of increased future effic
On 6/1/06, Ludovic Courtès <[EMAIL PROTECTED]> wrote:
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> Yet, as long as the current GC is more efficient (as measured by
> performance tests), there is no reason to switch, right?
Well, it's still unclear whether the current GC is more efficient, a
Hi,
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> Yet, as long as the current GC is more efficient (as measured by
> performance tests), there is no reason to switch, right?
Well, it's still unclear whether the current GC is more efficient, and
how much more if it is. Furthermore, the GBGC c
Hi,
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> The per object GC stats are a hack of mine, and although I would be
> sad to see it go (it makes debugging memory leaks easier), I think
> getting BGC is worth it. I don't see the point of the general GC
> stats. I think I've never ever used it
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Fascinating! Assuming we can resolve the details you have listed,
> what are the other high-level pros/cons, apart from performance? Does
> this mean we would discard all Guile's own GC code? Also, is Boehm GC
> as sophisticated as the generational
Hi,
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> Boehm is generational, AFAIK.
>
> Virtually everyone uses BGC. GCJ, MzScheme, BigLoog, GNU Obj-C, etc.
Yeah, and it's actively maintained and actively used. The mailing list
is active as well and Hans Boehm has been very helpful answering my
qu
In article <[EMAIL PROTECTED]>,
Neil Jerram <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> Sorry for the long mail and if you have any comment, don't hesitate!
>
>Fascinating! Assuming we can resolve the details you have listed,
>what are the other high-level pros/co
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>* GC Stats
>
> I haven't thought much about this, but it looks is quite problematic.
> We probably can't provide the level of details of `gc-stats'. And we
> cannot either provide per-object-type information as currentl
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Sorry for the long mail and if you have any comment, don't hesitate!
Fascinating! Assuming we can resolve the details you have listed,
what are the other high-level pros/cons, apart from performance? Does
this mean we would discard all Guile's own G
Hello,
Some time ago, I started porting Guile to Boehm GC, mostly in order to
see whether this was feasible without loss of functionality and while
remaining as compatible as possible with the current Guile.
The good news is that I got to a "working", almost as feature-full, and
mostly-compatible
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>>
>> http://www.xs4all.nl/~hanwen/public/guile/guile-boehm.gz
>>
>> note that this is a patch for the "old" GC code, before I took a stab
>> at rewriting.
>
>The good news is that it looks quite simple! The main changes
Hi Han-Wen,
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> it's here,
>
> http://www.xs4all.nl/~hanwen/public/guile/guile-boehm.gz
>
> note that this is a patch for the "old" GC code, before I took a stab
> at rewriting.
The good news is that it looks quite simple! The main changes are
locate
[EMAIL PROTECTED] (Ludovic =?iso-8859-1?Q?Court=E8s?=) writes:
> Hi all,
>
> Integration of Boehm's GC within Guile was discussed at length in the
> past, especially back in 2000. Apparently, Han-Wen even got to the
> point of having an preliminary implementation of Guile that uses it[0].
> Unfor
Hi all,
Integration of Boehm's GC within Guile was discussed at length in the
past, especially back in 2000. Apparently, Han-Wen even got to the
point of having an preliminary implementation of Guile that uses it[0].
Unfortunately the URL mentioned there is no longer valid.
Han-Wen: Could you su
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>Hi all,
>
>Integration of Boehm's GC within Guile was discussed at length in the
>past, especially back in 2000. Apparently, Han-Wen even got to the
>point of having an preliminary implementation of Guile that uses it[0].
48 matches
Mail list logo
