commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] patch submitted for commons-math sparse matrix support
Date Tue, 02 Dec 2008 13:19:39 GMT

----- "Ted Dunning" <ted.dunning@gmail.com> a écrit :

> 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)?

This is not used for LUD but only for simpler operations (multiplication, addition, subtraction).
For these operations, the algorithm is almost reduced to one operation, so a single getEntry()
instead of a direct access result is really a performance bottleneck. This does not mean it
is the only point to improve, but it was the easiest one.

The more I think about it, the more I feel your proposal to change the underlying layout is
the way to go. I am ready to do it if you want once I have completed a first working implementation
for SVD (even if this first implementation is not fast enough). I would however be interested
if you could provide a few pointers to me, as you may have noticed, linear algebra is not
my main field of activity.

What would you suggest ? How is storage handled in colt ?

Luc
 

> 
> 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 <Luc.Maisonobe@free.fr>
> 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:
> > http://markmail.org/message/36fgg7vx6gzd3ziu. 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
> DeepDyve
> 4600 Bohannon Drive, Suite 220
> Menlo Park, CA 94025
> www.deepdyve.com
> 650-324-0110, ext. 738
> 858-414-0013 (m)

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


Mime
View raw message