Re: [patch] multi-cells (was: Re: Proposal for a Guile binary file format)

[Greg Harvey <Greg dot Harvey at thezone dot net>]

Michael Livshin <mike@olan.com> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > I think three cells might be going a little far... maybe it should be
> > a configuration option; if not, you end up wasting a pile of heap
> > space for objects that aren't going to be very common (like, if you
> > have one guardian, 256k is way too much memory to be using for it,
> > regardless of how cool guardians are ;).
> 
> well, the converting of innocent things like guardians and asyncs to
> multi-cell representation was going too far, indeed.  got carried away,
> I guess ;)

Actually, I do think that if since we're supporting multi-cell heaps,
we might as well take advantage (if not, then we do end up with a lot
of sparsely populated heaps, even for the two cell heaps). The main
things I dislike about 3 cell heaps is:

1) Very few objects would use them, and those objects tend towards
   rare.
2) I'd have to wade into the awe inspiring collection of gc macros to
   make sure that it would work if there was a 3 there ;)
3) Complex numbers scare me.

> > For complex numbers, I don't
> > know that you'd see much of a performance benefit, simply because the
> > overhead of following an extra pointer is almost totally overshadowed
> > by the complexity (heh) of most complex operations; the cost of
> > collecting another full sized heap should be much larger than doing a
> > small malloc when a complex number is needed (though it probably
> > wouldn't be a bad idea to use the list of small chunks idea for
> > objects that would want to create a 3 cell object).
> 
> hmmm.  this whole arithmetic thing has a very "functional" flavour to
> it, i.e. you just cons new numbers all the time.  so either you have a
> Stalin-style bad-ass optimizing compiler that does lifetime analysis
> and eliminates consing with extreme prejudice, or you optimize the
> consing itself.  

Well, we could do with a bad-ass compiler (hobbit's a bit too mellow
for my liking >;'). For the most part, you get away with integer
arithmatic, which is usually pretty small, so there aren't any consing
problems. With doubles on the heap, there's another improvement, so
you can balance your check book a few msecs faster :). By the time you
get to heavy complex math, you should probably be thinking about
putting this stuff in a c library for speed, so it all works out
without 3 cell heaps ;)

> as for wasting space -- I agree.  maybe having a much
> smaller initial heap for the triple-cells would be a good idea.
> thinking about it some more, maybe there shouldn't be any initial
> triple-cell heap at all -- you want complex arithmetic, you pay.

Not a bad idea (ok, so that's actually the way I implemented 2 cell
heaps ;). The only annoyance that I see with this is that it gives you
a whole new range of variables for setting the sizes of the different
heaps, since you would want the 3 cell heaps to be constrained to
smaller sizes. 

> > -- 
> > Greg, now I have to see if the two cell objects break my gc changes ;)
> 
> yeah, check this.  double-cells are here to stay, in one form or
> another, Goops simply cries to use them.

They've actually been in there (my gc patchs, in their many guises)
for a really long time, but I didn't get around to rewriting anything
to use them (I was going to do doubles sometime soon, but now I don't
have to :). Except for a few little bookkeeping mistakes they actually
worked (a pleasant surprise, I was almost sure they'd be rotting by
now).

-- 
Greg