On 05/26/2010 03:51 PM, Charles Oliver Nutter wrote:
The automatic overflow into Bignum is a
real hassle since we can't represent operations against both long and
Bignum in the same code. I'm open to suggestions on that end of
things...it's really the only thing preventing us from attempting
primitive specialization for Fixnum right now.
This is another example of where structs would be helpful. That would
allow:
struct Integer {
int ivalue;
int[] iwords;
}
If the value fits in 32 bits then iwords is null. Otherwise, we
allocate an array of "big-digits". The codepath for add(i1, i2)
is:
if (i1.iwords == null && i2.iwords == null) {
long sum = (long) i1.ivalue + (long) i2.ivalue;
int isum = (int) sum;
if (sum == isum)
return Integer { ivalue: isum; iwords: null };
/* OPTIONAL - skip if inlining
else
return Integer.makeFromLong(sum);
*/
}
return Integer.slowAdd(i1,i2);
Kawa basically does this using a regular class gnu.math.Integer,
and "small" Integers pre-allocated. That is one reason Kawa's
arbitrary-precision handling is (mostly) noticeably faster than BigInteger.
(Some of that could be achieved by further tweaking BigInteger.)
However, if we could use structs, we can avoid heap-allocation
in those cases where we know the values are integers though
not necessarily fixnums. JVM optimizations could further optimize
this, especially if struct Integer is a standard part of the platform.
--
--Per Bothner
[email protected] http://per.bothner.com/
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
