[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] More efficient numbers integration through
Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace"
Sun, 19 Apr 2015 22:28:53 -0400
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
> 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
Re: [Chicken-hackers] [PATCH] More efficient numbers integration through "scratchspace", Felix Winkelmann, 2015/04/21