----- "Ted Dunning" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
