[kaffe] Removed GMP math?
Per Bothner
per at bothner.com
Thu Feb 28 14:46:08 PST 2008
Dalibor Topic wrote:
> Indeed. What I want though, is to see the GMP-based math code enter GNU
> Classpath, so that it gets maintained collaboratively, and becomes a
> shared feature among all the different GNU Classpath based VMs, rather
> than something only Kaffe is good at.
GMP-based math code *is* in ClassPath. The implementation of
java.lang.BigInteger was designed so that it could make use
of GMP's lower "MPN" layer. This is (or at least was when I wrote
it) the lower-lever layer that did the actual computation, without
memory allocation. And this is the layer partly implemented in
assembler.
So what we did for BigInteger (based on code I wrote for Kawa),
was write an emulation in Java of MPN, using int arrays (i.e.
Java arrays), using the same calling conventions. This is
gnu/java/math/MPN.java. The hope was that would be able to
replace MPN.java by the actual mpn part of gmp. This would
have been very high-performance, expecially if using the
low-overhead CNI.
As for a I know, no-one every tried plugging in mpn. One
complication is that BigInteger assumes MPN is an array
of 32-bit "limbs"; things would be more messy on a 64-bit
port port. Plus of course if you're using JNI, it's going to
be hard to make up for the overheads of JNI; in that case,
you might as well stick to MPN.java.
The performance of MPN.java is actually pretty good as is.
One of the tricks that BigInteger does (and the Kawa code it
is based on ever more so) is special-case for the case that
one or both operands fit in a 32-bit word. In tha case, it doesn't
even allocate an array, and doesn't even call MPN - it just
uses regular int or long arithmetic. Even in application that
use BigInteger, this is a worthwhile optimization. It's even
more critical if you want to provide infinite-precision
integers by default for a language or library.
--
--Per Bothner
per at bothner.com http://per.bothner.com/
More information about the kaffe
mailing list