From dev-return-111667-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Tue Dec 02 13:20:15 2008 Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 29673 invoked from network); 2 Dec 2008 13:20:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Dec 2008 13:20:14 -0000 Received: (qmail 10814 invoked by uid 500); 2 Dec 2008 13:20:25 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 10737 invoked by uid 500); 2 Dec 2008 13:20:25 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 10726 invoked by uid 99); 2 Dec 2008 13:20:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 05:20:25 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [212.27.42.91] (HELO wmproxy1-g27.free.fr) (212.27.42.91) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 13:18:54 +0000 Received: from spooler6-g27.priv.proxad.net (spooler6-g27.priv.proxad.net [172.20.243.236]) by wmproxy1-g27.free.fr (Postfix) with ESMTP id 20CCE4E153 for ; Tue, 2 Dec 2008 15:10:30 +0100 (CET) Date: Tue, 2 Dec 2008 14:19:39 +0100 (CET) From: luc.maisonobe@free.fr To: Commons Developers List Message-ID: <1408131315.412791228223979354.JavaMail.root@spooler6-g27.priv.proxad.net> In-Reply-To: <57374353.412211228223812389.JavaMail.root@spooler6-g27.priv.proxad.net> Subject: Re: [math] patch submitted for commons-math sparse matrix support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.20.243.42] X-Mailer: Zimbra 5.0.11_GA_2627.UBUNTU8_64 (ZimbraWebClient - [unknown] (Linux)/5.0.11_GA_2627.UBUNTU8_64) X-Virus-Checked: Checked by ClamAV on apache.org ----- "Ted Dunning" a =C3=A9crit : > 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, a= ddition, subtraction). For these operations, the algorithm is almost reduce= d to one operation, so a single getEntry() instead of a direct access resul= t is really a performance bottleneck. This does not mean it is the only poi= nt to improve, but it was the easiest one. The more I think about it, the more I feel your proposal to change the unde= rlying 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 imple= mentation is not fast enough). I would however be interested if you could p= rovide 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 =20 >=20 > 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. >=20 > 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. >=20 > On Mon, Dec 1, 2008 at 2:52 PM, Luc Maisonobe > wrote: >=20 > > 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. > > >=20 >=20 >=20 > --=20 > 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