Fixnums: last mile for JRuby math perf
Charles Oliver Nutter
charles.nutter at sun.com
Mon Jun 16 14:25:43 PDT 2008
Per Bothner wrote:
> Charles Oliver Nutter wrote:
>> On a side note: any recommendations for optimizing fixnums on current
> "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.
More information about the mlvm-dev