Re: [eigen] nesting |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] nesting*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Sun, 7 Feb 2010 10:09:44 -0500*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Z2aogsH3cg0ZWT6Hs8oJjpQgvK6vjWigTvSxI1NXUt4=; b=xV3WrvDFj78Epm5WG+8Hx/fQvTzhP2B4PxwZgMD62m37MDBo3UM55EZ6rhC2Jy5vid ZAfbbq/MPY7z0UvNM0NwSldfgqFNEHboryVVaTxkOJmJugkzG6hS7huqEAMQNTl0hCns 83q3UP5Ux52+D/NgANvKTLHecFh22EGtbGiBE=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=blUNXFaRQvXF7vprpcebuXEvNcp/1iqX0Qi6PXvyFGgoP/6ruCyUeF81YQBAXs5hN3 XsmjrHFJAFdngZSjFayw5e7dVasSem2Kgk568cqWOaXQG+12O49kvPZgjUbl/8wyCq78 jfk4uGkFZdC6z8UYfK7mYy+UOcUMYZp85rnWg=

2010/2/7 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: > Do I remember correctly that the need/reason for evaluating products > into temporaries arises from the fact that the resulting code > (assuming no copies) is more efficient? Isn't this effect now shadowed > by the mallocs? There are other motivations, too. Evaluating large products into temporaries, allowing to use the cache-friendly functions, instead of having to evaluate them coefficient by coefficient inside of a larger expression, can be hugely important. It can be more that 10x. (To make things worse, imagine that the bigger expression can't be vectorized). Moreover, it's not like we have to choose between 2 optimizations: we should be able to get both simultaneously. > Regarding the problem in general, we should try really hard to prevent > the need for using a syntax like this > > (a*b).conjugate().nesteByValue().transpose() > > or related code requiring to call .eval() in order to prevent crashes. > I hope we agree on this? Sure! That's also one more big reason why your nest-by-value changes are so good! > > Currently, I am also a little bit confused about the following code > (from the forum): > > double p = (P.transpose * P).diagonal().sum(); > > It is clear that what we can do in 2.0 > > double p = (P.transpose * P).lazy().diagonal().sum(); > > leads to way more efficient code than the default expression. This > would remain an issue (or better source for improvements), even if the > problem at hand with the temporaries were fixed. What I am trying to > say is that it might be a nice feature to be able to override the > default behavior and deactivate eval-before-nesting. So, reintroduce .lazy() as an advanced feature for users who know what they're doing. Good idea, it doesn't hurt as long as we explain in the documentation that users should first try noalias() as it is in most cases what they want. But let's also say that > double p = (P.transpose * P).lazy().diagonal().sum(); can equivalently (and even more efficiently) be done as: double p = P.array().abs2().sum(); And this is not an isolated special case. The "diagonal in a product" and more generally "some coefficients in a product" expressions inherently simplify as expressions in terms of the coefficients. > Finally, I think I need to update the 3.0 TODO list. Personally, I > consider this whole problem a blocking, high-priority issue for 3.0. I think we all agree on this. Good idea, and anyway I don't think we can forget about it now :) Benoit > > Cheers, > - Hauke > > On Sun, Feb 7, 2010 at 10:26 AM, Gael Guennebaud > <gael.guennebaud@xxxxxxxxx> wrote: >> also note that the nest everything by reference approach we have in Eigen >> 2.0 also leads to unnecessary copies: >> >> Indeed since (a*b).adjoint() is compiled as: >> >> (a*b).conjugate().nesteByValue().transpose() >> >> the result of a*b gets copied once from the Conjugate to the Transpose >> expression. >> >> Finaly, let emphasize again that with either the current devel approach or >> the evaluator I described in the previous email, dynamic sized matrices can >> be easily worked-around using kind of shared pointers or a list of >> temporaries respectively. So the discussion might be focused on fixed size >> objects. >> >> gael > > >

**Follow-Ups**:**Re: [eigen] nesting***From:*Benoit Jacob

**Re: [eigen] nesting***From:*Gael Guennebaud

**References**:**[eigen] nesting***From:*Hauke Heibel

**Re: [eigen] nesting***From:*Hauke Heibel

**Re: [eigen] nesting***From:*Benoit Jacob

**Re: [eigen] nesting***From:*Hauke Heibel

**Re: [eigen] nesting***From:*Benoit Jacob

**Re: [eigen] nesting***From:*Hauke Heibel

**Re: [eigen] nesting***From:*Benoit Jacob

**Re: [eigen] nesting***From:*Gael Guennebaud

**Re: [eigen] nesting***From:*Gael Guennebaud

**Re: [eigen] nesting***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] nesting** - Next by Date:
**Re: [eigen] nesting** - Previous by thread:
**Re: [eigen] nesting** - Next by thread:
**Re: [eigen] nesting**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |