commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject Re: [math] re: move to Apache Commons
Date Wed, 12 Nov 2003 20:17:06 GMT
Phil Steitz wrote:
> Recent comments have suggested that Java may not be suitable for numerical
> computation (a view that I do not share)

Well, I think this should be put into context. Let's examine some
approaches to numerical computation:
1. A cleanly designed library of commonly used, somewhat low level
  functionality, like [math]. While it is relatively easy to build
  solutions for complex problems, this approach suffers from lots
  of temporary object creation and data copying. This is hard to avoid
  in Java without giving up data encapsulation and providing ample
  opportunity to users for shooting themselves in the foot. See the
  constructor of CubicSplineFunction for an example.
2. Provide solutions to higher level problems. Inline the code for
  the lower level functionality, do memory allocation less dynamically
  and weight the usage of abstractions carefully against possible
  object proliferation. For example in a ray tracer, use the vector
  components explicitely instead of using vector objects.
  This is, in general, noticably faster than approach 1, and an increase
  of *two* orders of magnitude is possible, although not necessarily
  Profiled and well optimized Java code run on a HotSpot JVM can be on
  par with average C code with regards to performance.
3. Get a highly optimized C/C++/FORTRAN library (possibly including a
  compiler), which takes processor architecture, cache size and
  organization and whatnot into account. A performance improvement of
  another order of magnitude compared to approach 2 is not unheard of.
I tried an EMF simulator two years ago, and when built on a generic
Java library, very similar to RealMatrixImpl, a 1000x1000x1000 data
point simulation run all night. Switching to approach 2 brought it
down to roughly 5min, barely enough to fetch a coffee. The real good
stuff, using C and tricky algorithms specifically designed for EMF
simulations, is nearly interactive, in the 5..10s range.

Summary: whether Java programs can be used for tackling numerical
problems depends on the problem, the problem size, how you want
to solve it, and the tradeoffs you are willing to consider.

> some design/refactoring decisions made some time
> ago that moved things more in the "framework" direction in commons math.

Hm. There are reasons that there are usually a bunch of different
algorithms for solving seemingly the same problem. Which specific
algorithm should be used can heavily depend on the higher level
problem, and a good choice can be a really huge win. And yes,
unsuspecting users are regularly bitten by stock textbook solutions
which are either much too slow or fail unexpectedly.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message