Ted Dunning a écrit : > Dang. > > That is fast. > > What size matrices was this for? > > On Thu, May 14, 2009 at 12:09 PM, Luc Maisonobe <luc.maison...@free.fr>wrote: > >> Some benchmarks I did a few weeks ago showed the new [math] linear >> package implementation was quite fast and compared very well with native >> fortran libraries for QR decomposition with similar non-blocked >> algorithms. In fact, it was 7 times faster than unoptimized numerical >> recipes, about 2 or 3 times faster than optimized numerical recipes, and >> very slightly (a few percents) faster than optimized lapack with Atlas >> as the BLAS implementation. Faster QR decomposition required changing >> the algorithm so the blocked lapack implementation was the only native >> implementation faster than [math]. >> >
Medium size, up to 600 if I remember correctly (I don't have the curve available here). The pattern with O(n^3) was clearly visible so the result can be be extrapolated for medium size I think. I did not check larger matrices like 3000 or more, results may be different. Beware, that was one algorithm only: QR decomposition and on one host only (AMD64 phenom quad core, Linux, sun Java 6 on one side, Gnu fortran on the other side). GNU fortran is not a very fast compiler so the result would obviously be very different with a better compiler. The purpose of this test was not to say that Java is faster, it was to show that the performance difference between Java and fortran was smaller than the difference you get by changing algorithms (in this case blocked vs. non-blocked). I was surprised by the results. For other kind of algorithms, mixing linear algebra, trigonometric computation, ODE integration, root searching ... I often see performance differences of about a factor 2, which in my opinion is a factor similar to other changes one can do (algorithms, CPU, BLAS, compiler, parallelism, memory ...). Of course, when comparing an highly optimized algorithm with the perfect cache size, and the best compiler to a standard setting we can get very different factors. So do not take these numbers for granted. Trying to get the fastest computation is not the purpose of [math]. It should be reasonably efficient with respect to other libraries, including native ones, but is not dedicated to speed. It should remain a general-purpose library. Luc --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
