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

[Michael Livshin <mike at olan dot com>]

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 ;)

> 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.  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.

> -- 
> 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.

-- mike