luc.maison...@free.fr wrote:
Hello,
I will give a talk on commons-math June 25th at a symposium organized by one of
the technical competence centers (CCT) at the french space agency (Centre
National d'Études Spatiales, CNES).
The theme of the symposium is on high performance computing and the organizer
asked me to present what we have done recently on commons-math.
I have a 45 minutes slots. I think I will first speak about general wrong ideas
about java and performances (some myth busting), then about the simple memory
rearranging we did with the last linear algebra classes and finish with some
comparisons results with respect to Numerical Recipes (optimized and not),
Lapack and Atlas (optimized and not), different algorithms in Lapacke and
perhaps another BLAS implementation. I will also tell about the future work
after 2.0 with MJT and native BLAS.
Do you have some ideas I should put on the slides or some material I could
present ?
Luc
Sorry if this is too late to be useful, but having thought some more
about this, I have a couple of more ideas that might be interesting to
talk about.
1. Design decisions made to support flexibility while delivering good
performance across a broad array of use cases. Throughout [math] we
try to do this. It is hard and we are by no means perfect or "done."
Again, showing that is a good way to get more people interested in
contributing. The matrix classes are a good example. The progression
from RealMatrixImpl -> current variety of implementations illustrates
the evolution.
2. Tradeoffs forced by optimization. The "shove everything back into
.linear" decision is a good example of this.
3. De facto API standards vs language-specific APIs - IEEE 454, C99x-G
are two more examples of this as well as the Lapack/BLAS. Our approach
thus far has been to avoid unnatural acts with Java or things that will
cause bad performance impacts, carefully documenting all of our decisions.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
