Re: [eigen] nesting |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] nesting*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Sun, 7 Feb 2010 12:38:11 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=7elWlXynqI8un0KfVWJQH37i2buvL2axM65k0FTsBUI=; b=EvdU5n3ju5PsyuxNep4EmJ5hdjh12oRIdooq/2k76yc4fICe7jjtB9CKx6tw3TdPPI 9qdoxDNvGB7WvILaJEYhA0p+k9KY2TdeWMGGFFdq3RrmfgbmLBVGwWAiRIYDkKI7z0Sw eZHjzFCNYqql1W1rRFXBzAcf672lnlZXwCTRw=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jZxzG+Q3T8oKe7bLTEoqNObEBGGiwaeJRJ7zYHdZFS299msNgzBSV1sjR1iF5s3QXn ocddsjC4en19hW6qQRgKbAt0FaUnmo7eLYAEaYOtmj09qNxWAc7N7KvrF0pbIz4Mk/P8 LHJcLcMu5R0FlPBZmPzZLZHDLJOVSa0qK7+Iw=

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? If that is the case, how about this approach: + instantiate temporaries as shared ptrs only when the return type of a product has dynamic size + for fixed size objects don't even create a temporary but simply evaluate the expression as if all sub-expressions were lazy 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? 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. 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. 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:*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

**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/ |