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@xxxxxxxxxxx http://per.bothner.com/
