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.


Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> mlivshin@bigfoot.com writes:
> > > most home-brew GC's aren't as sophisticated as Boehm's. Perhaps
> > > GUILE's is.
> > 
> > for Scheme, yes.  it may be that the Boehm GC is more efficient in
> > what it does (in some areas, certainly), but the Guile GC simply has
> > to do much less, as it's mostly precise.  but let's see where you get
> > with tuning BGC and making it not just scan everything.
> 
> I don't quite understand. Isn't BGC also mostly precise if you mark
> strings & floats as being atomic?  (Assuming that most memory is in
> the form of Scheme data, and not auxiliary data structs).

there's also uniform (numeric) vectors (easy, just atomic), smobs
(harder) and structs (not hard).

> The bad news: i looked some more, and I can't find any tuning, except
> for allocing atomic and stubborn (permanent) objects.

you can allocate "typed" objects, but the only exported interface to
that is by way of describing your types with bitmaps (which should be
sufficient for structs, but not smobs).  it's possible to assign your
own mark functions, but you'll have to dig in typd_malloc.c to
understand how, the API isn't exported (or at least wasn't in BGC
4.13, perhaps things changed).

> And there is a ratio specifier..that sets the ratio between wasting CPU 
> and wasting memory, meaning that my previous benchmarks are worthless
> (sigh.)

why?  the time result should be valid, shouldn't it?

> > now, if you don't want to go the `main'-capturing route, you *have* to
> > know where the C stack begins.  but if the Scheme evaluator doesn't
> > use the C stack, all you have to guarrantee is that your C procedures
> > are called from Scheme
> 
> that means you can't call C-procs from C. I think that is a loss.

the idea is that you can, but you must tell that you want the stack
area beginning from the call site to be conservatively scanned.

> BTW, I looked at Boehm briefly. It finds the stack using a big
> #ifdef. For linux it simply is 0xc0000000

yes, and for libc6 it's some variable, and...

> > also, it'll be hard to support the current API where you can setup an
> > exception-catching context in C code.  no great loss, I think.
> 
> no, especially since you can set this catch up yourself when you need
> it. (that's possible, isn't  it?)

in Scheme, yes.  (did I understand you?)

-- 
All ITS machines now have hardware for a new machine instruction --
BOT
Branch On Tree.
Please update your programs.


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