commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Dunning" <>
Subject Re: [math] patch submitted for commons-math sparse matrix support
Date Mon, 01 Dec 2008 23:01:40 GMT
Is performance in LUD normally achieved by fast element access?  Or is it
done by using higher order operators on a view of a row (or column)?

I know the the Colt package made the argument that the latter it far
preferable.  I also know that Jama didn't do this, but was very hard to
extend as a result.

The colt approach was to require the matrices provide row, column and
submatrix view operations and that vectors and matrices support functionally
oriented destructive updates.  This can be hard for users to understand so
you generally have to provide more algebraic interfaces as well, but it can
work wonders for performance.

On Mon, Dec 1, 2008 at 2:52 PM, Luc Maisonobe <> wrote:

> For now, one thing  that bother me is the removal of the dedicated code
> that explicitely avoided getEntry(). This was added a few months ago for
> performance reason, since the previous generic code was painfully slow.
> The trick with the ClassCastException allows really fast check since the
> virtual machine can completely optimize it out in some cases, it is an
> enhancement of what was discussed here:
> Our discussion at that
> time was that the more common case (RealMatrixImpl) should be as
> efficient as possible (and Ted wants now it to be even faster by
> changing the underlying storage which is a good thing). This trick is
> not beautiful perfectly generic code, it is a pragmatic way to be fast
> in a common case and removing it will most probably induce poorer
> performances.

Ted Dunning, CTO
4600 Bohannon Drive, Suite 220
Menlo Park, CA 94025
650-324-0110, ext. 738
858-414-0013 (m)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message