Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace"

[John Cowan]

Peter Bex scripsit:

> I managed to drastically reduce the overhead of the full numeric
> tower in core by introducing a new memory allocation area: 

This design sounds ingenious.  A few questions:

> The scratch area is seen as an extension of the nursery: the
> C_demand() and C_stack_probe() checks will add the size of the scratch
> space to the stack's size, and trigger a minor GC when the sum of the
> two exceeds the maximum nursery size.

So when a bignum needs to be allocated for the first teim, a scratch
space is alloca()ed?  How big is it?  It sounds like it needs to be
big enough to hold a sufficient number of biggest-bignums to perform a
single operation.

> a cplxnums containing two ratnums, which both contain two bignums will
> be correctly updated, regardless of where any of the 7 objects lives.

Compnums, rectnums, and ratnums are already fixed-size, so there is
no obvious reason to allocate them in the scratch space rather than
on the regular C stack.

It seems to me that there needs to be some way in the new design to force
part of the old behavior: for overflow and for / of integers to return
a flonum.  Notoriously, Scheme programs on full towers can get horribly
slow because they generate bigger and bigger ratnums, and any time where
efficiency beats accuracy, you want to switch to flonums.  This is often
done by inserting judicious decimal points into the constants in the
program, but it would be better to make it a switch of some sort.

-- 
John Cowan          http://www.ccil.org/~cowan        address@hidden
BALIN FUNDINUL          UZBAD KHAZADDUMU
BALIN SON OF FUNDIN     LORD OF KHAZAD-DUM