Math project or subproject (original) (raw)

Patrick Wright pdoubleya at gmail.com
Sun Jan 31 17:02:27 UTC 2010


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/viewbug.do?bugid=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 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



More information about the core-libs-dev mailing list