Fixnums: last mile for JRuby math perf

[Charles Oliver Nutter]

Per Bothner wrote:
> Charles Oliver Nutter wrote:
>> On a side note: any recommendations for optimizing fixnums on current 
>> JVMs?
> 
> "Optimizing fixnums" is of course a number of different problems.
> One is "optimizing generic arithmetic" on unknown types - most
> of which will be fixnums.

Ok, be pedantic :) I meant optimizing arithmetic on Fixnum reference 
types. But on a larger scale, I think the whole problem is worth 
discussion and resolution; we have benchmarks now that appear to be 
limited by the cost of dealing with all those Fixnum objects, rather 
than the math itself.

> Kawa does pretty well on optimizing arbitrary-precision integers.
> It wins over java.math.BigInteger by using just two fields, one
> which is an int and on is an int[].  The latter is only non-null
> when the value of the integer doesn't fit in the bounds of int.
> I think this would be a worthwhile optimization for BigInteger.
> The various operations "fast-path" the common case when the values
> fit into an int (and thus the int[] is null).

FWIW, I'm not particularly interested in the performance of 
arbitrary-precision math...for the most part I can fake it by swapping 
out the backing store or mimicking "better" impls in our current Bignum.

> Kawa also does preallocate the number -100 .. 1024.  I haven't
> done any measurements to see if this is a good range to
> pre-allocate - that might be useful to get some numbers on.

We do -127 to 128. I've bumped the range larger and it seems to have 
only a small impact on performance at the cost of a larger startup time 
to initialize the values. The current size is based on java.lang.Integer 
from OpenJDK, and I would expect quickly diminishing returns for 
anything outside that range.

- Charlie