[Chicken-hackers] [PATCH][5] numbers integration

[Peter Bex]

Hello CHICKEN hackers,

I finally finished integrating the code from the numbers egg into CHICKEN 5!
This is quite a big change, so I decided not to send patches to the list,
instead you can find this work under the "numbers-integration" branch.
If you were curious and checked it out before, you might need to
git reset --hard it, because I've rebased many times while working on this
in order to keep every commit self-contained and keep things easier to
understand.

If you decide to merge it, please *DO NOT* squash this into a single huge
commit, as that will just make it much more difficult to figure things out
when digging through the history!

Anyway, on to the description:

This branch adds full numeric tower support: bignums, ratnums and cplxnums
are added.  Bignums are the only "native" type, the ratnums and cplxnums
are simply record types that are handled specially in a few cases.  The
value of the type slot (just a symbol) is tracked by the garbage
collector, much like the error hook and other such symbols that need to
be accessed from C.

Bignums get a new type bit (there were two unused ones, so now only one
is left), and are treated as bytevectors, even though they really store
machine words.  This is because that's the easiest way to handle them
in the garbage collector; just like flonums, the GC doesn't try to access
the contents but copied the whole data blob verbatim, which is fine for
bignums.  The contents are however accessed by the machine word and in
the division and multiplication routines, by the halfword.

Attached is also a comparison of a "chicken-benchmark" run of chicken 5
with and without the numbers integration.  As you can see, this change
has quite a large negative performance impact on several of the
benchmarks (most notably fibc, nboyer, nestedloop, sboyer and takr):
the total time to run all the benchmarks has doubled.

This is due to the fact that every numeric operation which can return
a newly allocated number will necessarily need to be in CPS context,
because if it has to allocate a large number, this may trigger a garbage
collection.  This means that functions which could be inlined into a
tight loop in C before will now need to create a continuation object,
put the live values in it and call the function, which will then invoke
the continuation.  This big performance impact could be a reason to
decide not to integrate this patch.  The fact that numbers dispatching
is extremely hairy is another reason why Felix always resisted adding
the full numeric tower code to CHICKEN.

I've reworked all the code that I could find which returned or accepted
flonums as a substitute for large integers, but I'm sure I didn't find
every single case.  There are bound to be legion bugs all over the code,
as a major change like this tends to cause.  Please, give the branch a
try and let me know what needs more work.

You will need to build a bootstrap CHICKEN first, and then build the
branch with that.

While working through this stuff, I simply removed a lot of rewrite
entries from c-platform.scm; these haven't been replaced with optimized
versions for the numbers code, but I'm not sure we want to do that,
now that we have types.db (which is much easier to maintain).  These
rewrite rules have been removed, but not the actual code that performs
the rewrites, which we can now remove.  Also, the C functions that
these rewrites used to expand to have been marked OBSOLETE, but they
can't be removed just yet, because that makes bootstrapping impossible.
If the numbers branch is integrated, we can remove them after we publish
the first snapshot tarball.

Cheers,
Peter

perf-diff
Description: Text document

signature.asc
Description: Digital signature