commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] talk about commons-math
Date Sun, 21 Jun 2009 16:30:40 GMT
luc.maisonobe@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message