This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: boehm & guile, success report.


mlivshin@bigfoot.com writes:
> > 
> > I don't deal with anything, Boehm  is designed to be a drop-in
> > replacement for malloc. Since I expect that lots of C programs also
> > allocate large numbers of small obejcts, it should work reasonably
> > with GUILE.
> 
> ah, you mean that every SCM_NEWCELL is actually a GC_malloc()?  this
> is a valid approach,

yep.

> but it'll require some tag structure redesign to
> be really usable.

why?

Benchmark:

GCBench.scheme (see my software page).

* 1.4:

308.38user 0.44system 5:15.53elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (787major+6941minor)pagefaults 19swaps

* Boehm (gengc turned on)

523.72user 35.74system 10:40.71elapsed 87%CPU (0avgtext+0avgdata
    0maxresident)k
0inputs+0outputs (19176major+2589136minor)pagefaults 5685swaps

Performance sucks, but keep in mind that this was a 45-or-less-minute
hack; I reckon boehm must have some more tuning options than I used (I
used none).

> > One of my colleagues did a  literature survey on GC, and found out that
> > most compilers and interpreters got better by dropping their in-house
> > developed gc in favor of BGC.
> 
> I have at least one contrary experience, but I'm not allowed to tell
> where it was.
> 
> can you give a pointer to that survey?  (I hope it's online).

He just told he read this somewhere. I'll ask him sometime.  He
pointed out that most home-brew GC's aren't as sophisticated as
Boehm's. Perhaps GUILE's is. 

> > In any case Bigloo also uses BGC, so it should be feasible.
> 
> nobody said it's not feasible.  (MzScheme and Stalin also use it,
> IIRC).

we could glean some useful ideas from them, perhaps.

> [ in fact, in the long run, I think that it would be very worthwhile
>   to divorce the Scheme execution stack from the C one.  apart from
>   making continuations much cheaper, this would make the need to know
>   the C stack origin unnesessary, etc.  but that's stuff for a
>   separate discussion. ]

[going into separate discussion]

That does seem to make C-integration for normal applications hard ,
doesn't it?
-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]