[kaffe] Removed GMP math?

[Dalibor Topic]

Alan Eliasen wrote:
> Jim Pick wrote:
>> What's New In Kaffe 1.1.9
>> ----------------------------
>>
>> * Removed support for native big math.
> 
>    I have to admit, I was *very* disappointed when I saw this.  The fact
> that Kaffe could use the best-of-breed GMP libraries to perform
> operations with very large BigIntegers was the sole reason that I used
> and advocated Kaffe.  It was the one place where programs run under
> Kaffe could be enormously, incredibly faster than other JVMs, often by
> factors of 1000 or even 100,000.  The algorithms that replaced it are
> *vastly* slower for very large numbers.

Hi Alan,

You're right, and it was a hard decision to make. I've thought about it 
for a while, and I hope my explanation and proposed resolution below 
will make some sense.

>    Why was this done?  It constitutes a severe performance regression
> for many programs, and was already switchable so that it could be
> compiled in and used or not used at runtime if desired, or completely
> omitted from compilation if you didn't want it.

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.

The huge problem with maintaining class library code in Kaffe, rather 
than GNU Classpath, and GMP big math is a slice of very useful class 
library code, is that it ends up not being in sync with the rest of the 
class library, and does not get the level of shared attention between VM 
projects that code residing in GNU Classpath gets.

For example, the Java classes used by the GMP big math implementation in 
Kaffe differed in the exported APIs from those in GNU Classpath, and 
there was no bandwidth for an effort to try and maintain them in sync 
with the API jumps in javax.math from 1.4 (what they approximately 
implement in Kaffe) to 1.5 (GNU classpath's level).

That's a real maintenance problem, and from the level of volunteer 
activity around Kaffe, I think that the Kaffe project does not have the 
bandwidth to maintain class library code unless it is shared with other 
implementations, beside that from a social point of view, having free 
VMs compete on VM features, rather than class library features that 
could and absolutely *should* be shared is a lot healthier for the free 
VM community.

So I consider this to be an ugly, but necessary cut, for the long term 
health of the GMP math bindings: the GNU Classpath project has seen a 
set of patches by Raif Naffah, 
http://search.gmane.org/?query=28664&author=patch%40naffah-raif.name&group=&sort=relevance&DEFAULTOP=and&query=
around GNU Classpath's PR 28664, that have not been merged in for, as 
far I can tell, the lack of someone of your level of understanding of 
the problems having a javax.math that uses GMP solves in practice, and 
how much more efficiently it solves them, to push for the code to get 
proper review, and be included in GNU Classpath as an option.

What you'd get out of pushing GNU Classpath developers to pick up Raif's 
patches that got dropped on the floor, is a lot more choice regarding 
the VM you'd be able to use for your work, i.e. you wouldn't be 'stuck' 
with Kaffe, and could alternatively use IKVM, Cacao, JamVM, gcj, 
JikesRVM, if their performance or other characteristics suit your work 
better.

>    While I am working very hard at implementing faster algorithms for
> the OpenJDK project, my best algorithms are still factors of about 100
> times slower than Kaffe/GMP for many large numbers, and nothing one
> could do in Java could ever match their performance.

You're right, of course.

> 
>    How much trouble would it be for whoever removed these parts to
> revert those changes?  I think they were removed without concern for the
> people who use Kaffe for this very reason, and this reason alone.  For
> me, and the people that use Kaffe/GMP for work in number theory, this is
> a heartbreaking regression, and one that, quite frankly, makes Kaffe
> rather unsuitable for my use, as it tends to be about 20-25 times slower
> than other JVMs for most other programs.

I removed them myself, so I offer to produce a patch for you against the 
1.1.9 source tarball, that adds Kaffe's GMP code back in, rather then 
reverting the commit.

I think that GMP math needs to find a home in GNU Classpath sooner 
rather than later, and I don't want to delay that process, so I'd ask 
you to champion the inclusion of Raif's patch into GNU Classpath, so 
that we can make sure that Kaffe 1.1.10 and GNU Classpath 0.98 will work 
out of the box for your needs without regression.

Would that work for you? A patch for now from me, and you taking the 
lead on pushing Raif's code into Classpath?

cheers,
dalibor topic