This is another piece of my attempt at getting more speed out of the
`(rnrs arithmetic fixnums)' library. The idea is that this patch would
be applied to master. I think, at least in the current form, it is not
eligible for 2.0.x, as it messes up the VM opcode numbers, which breaks
all .go files, IIUC.
After this patch has been applied, the R6RS fixnums library can be
adapted to use the new primitive. I have locally already tried this,
and on top of the previous patch ("Take some lowhanging fruit to speed
up R6RS fixnum operations"), this one speeds up the ZIP benchmark by
another factor of 1.75, yielding a runtime of 15 seconds. The fxxor
benchmark added by the previous patch gets a ~3x speed boost.
Now, I'm still not entirely satisfied, but these two patches should
cover the lowest hanging fruits without changing the semantics of the
fixnum operations.
For well-behaved programs, it would not be necessary to do the checks
for fixnum-ness at all, neither for the arguments nor for the return
value. This would in effect alias the fixnum operations to their
non-fixnum counterparts, violating R6RS, which demands exceptions to be
thrown if arguments or return values exceed fixnum range. I conjecture
that this would give another noticable boost, as it would eliminate at
least a procedure call and the `fixnum?' checks.
I'd argue that deviating from R6RS in this area is not desirable; after
all I think the intention of the R6RS fixnum library is to provide
specialized operations so that implementations can provide fast-path
versions of the more general procedures when it is known that fixnum
range suffices -- the fact that fixnum arithmetic is actually *slower*
than general arithmetic on Guile is not a given, but an artefact of the
way they are currently implemented.
Ideally (at least speed-wise), all of the fixnum operations should be VM
primitives. I'm not sure if we have enough opcode space for that. It
also raises the question of maintainablity (which probably can be kept
in check with appropriate C preprocessor trickery), and how to deal with
the exceptions these procedures are required to throw. As we probably
don't want to tie the R6RS exception system directly into VM, I was
thinking of using a fluid containing a procedure that does the actual
exception throwing; that fluid could be set by some R6RS library.
Well, this is getting quite long already, so I'll stop for now. I'm
looking forward to any responses!
,,rotty
