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
