Math project or subproject

[Patrick Wright]

Hi Dima

I think a goal for such a Math subproject would be to engage in
active, constructive discussion with a wider community interested in
high-performance math libs on the JVM. The folks behind Apache Commons
Math and COLT are two obvious examples. I'm sure there has been
communication back and forth over the years between the JDK developers
and external groups on math libs, but I don't know of any public
repository for those discussions.

This is not to say that there isn't room for math libraries outside of
the JDK, or that top priority shouldn't be on backwards compatibility,
but it seems more open dialogue (especially public dialog on mailing
lists) would be welcome. In particular, in those cases where it's
decided that a certain "optimization" will not be added to the JDK,
the reasons will be recorded publicly and for posterity; and if the
factors influencing those decisions change over time, as the JVMs
improve and new CPUs come to market, then the decisions can be
re-reviewed later, again, based on open, public discussion.

In addition, I think that having an open-source micro-benchmarking
library for this purpose would be very helpful. It might not be
perfect or all-encompassing, but it would allow researchers and
tinkerers a base on which to test their own code, and on which to base
arguments of "improvements" to the current libs. In essence, it would
be like saying that the OpenJDK is written as it is because it works
well in these standard benchmarks, and if someone thinks they have
improvements, they have to prove it against the same benchmarks that
Sun/Oracle has used for their own decision-making.

There is/was a Sun project I mentioned on another JDK thread, Japex
(search online) which is a test harness for micro-benchmarking.
Perhaps something like this could provide a standard benchmarking,
with records of historical results, into which different tests could
be plugged. I don't have any reason to prefer Japex over Caliper or
another framework; in general I think that a framework that could take
care (at least) of isolating the warm-up phase, taking and recording
measurements, etc. would be better than people starting from scratch
in main() each time they write a benchmark.

Best of luck with your effort.

Regards
Patrick

On Fri, Jan 29, 2010 at 10:02 AM, Dmitry Nadezhin
<Dmitry.Nadezhin at sun.com> wrote:
> In my previous post I discussed choice criteria for performance enhancements
> in math libraries.
>
> I guess that in production projects Jdk 1.6 and Jdk 1.7 the main choice
> criteria is stability.
> This explains why changes to math stuff in Java are almost impossible.
> Here is a pair of examples:
> 1) The Karatsuba multiplication in BigInteger
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000225.html
> (contribution proposals)
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000229.html
> (proposals approved)
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000236.html
> (patch submitted)
> This patch is still not in OpenJdk tree.
> 2) Double.parseDouble(String s) loops infinitely on some inputs
> http://bugs.sun.com/view_bug.do?bug_id=4421494
> (one-line fix was suggested in bug database comment in 2004)
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html
> (fix was submitted again together with tests)
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003182.html
> (fix was scheduled for verification)
> This patch is still not in OpenJdk tree.
>
> I respect our "Java Floating-Point Czar" for keeping stability of mainstream
> Java.
> However, I suspect that some OpenJdk users prefer enhancements and bug fixes
> of old bugs in math libraries
> in exchange for a small risk of new bugs. Perhaps some new languages may
> need enhancements in OpenJdk math
> (scala, fortress, frink, fantom).
> http://www.scala-lang.org/
> http://projectfortress.sun.com/Projects/Community/
> http://futureboy.homeip.net/frinkdocs/
> http://fantom.org/
>
> What about more rapid enhancement of OpenJdk math in some project related to
> but separate from OpenJDK 6 and (Open) JDK 7 ?
> This may be a new Math project or a subproject of the Da Vinci Machine
> Project.
>
> I see such works which can be done in such a project.
>
> I) Jdk changes
> 1) bug fixing of known math bugs from bug database;
> 2) creating microbenchmarks for performance enhancements request
>   Keeping a collection of alternative implementations and picking currently
> fastest implementation
> 3) Static methods which performs arithmetic operations on doubles with
> RoundingMode.FLOOR and
> RoundingMode.CEILING for use in interval computations.
> 4) Arbitrary-precision classes:
>  Rational - rational numbers together with infinities and signed zero
>  Binary - floating-point binary numbers
> 5) Classes for some particular floating-point binary formats:
>  BINARY128, BINARY80.
> 6) Universal Comparator<Number> to compare values of different subclasses
>   of Number with each other. Different quiet and signalling relational
> operators
>  mentioned in IEEE 754r standard.
> 7) Implementation of forthcoming P1788 Interval Arithmetic standard
> http://grouper.ieee.org/groups/1788/
>
> II) HotSpot changes.
> I consider useful to intrinsify some methods from above (3),(4),(5),(7).,
>
> III) Quality
>  Perhaps the math libraries are a proper subject for Formal Verification.
>  Operation on numbers are easy to specify by formal tools.
>  It is easy to make long-live bugs in math libraries which can be detected
> by attempt to prove.
>  There are already tools to assist formal proofs.
> http://coq.inria.fr/
> http://lipforge.ens-lyon.fr/www/pff/
> http://gappa.gforge.inria.fr/
> http://why.lri.fr/
> http://krakatoa.lri.fr/
>
> What do people think about a Math project or subproject ?
>
>  -Dima
>
>