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*: Thu, 4 Feb 2010 17:35:06 -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; bh=YD9APlvg8LinUuPwrdmCrJPCSyOZ8KHbEkTZflsZHf4=; b=mL2xwvfuXCTxPJXtvQFI1XzXZ+i1hLKEjFwNmmkfGcxFZsdwCQr1Q3YfH5Oq1U6BQu MKNoLAFGam+csvpEEJJln6nynWDZg1qt/xmv0DOQKoYlsyZ1QWh1SAMDiRnPRIUvkK7H VI1F4shaWRcjzTT4Q2nUfYx+CTH6AsI7pwKIQ=*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; b=Pp7tJYFlbr76txfxyUSGRlWbn0eYnUY79culAur2SzBjaQkuxl5uCBlOwtyh89WOko Z0A/6nAFVx7+PybnQXxj+oXpzNjIZYD7bP6nhLrGnJAK7hbZn/d+Q82yZm992eIQmrbZ xJodLNmRXf+SWef7ZFtumX2wphJOGLGZqb8EA=

2010/2/4 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: > On Thu, Feb 4, 2010 at 11:22 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> 2010/2/4 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: >>> On Thu, Feb 4, 2010 at 11:11 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >>>> Just one thing that I don't follow: >>>> >>>> 2010/2/4 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: >>>>> Our real problem is the following: >>>>> >>>>> A*B + A1 + A2 + A3 + A4 + A5 >>>>> >>>>> creates 5 temporary matrices, the result of A*B is copied 4 times.... >>>> >>>> Why is it so? After A*B has evaluated into a temporary matrix, isn't >>>> it the same as >>>> >>>> tmp + A1 + A2 + A3 + A4 + A5 >>>> >>>> ? That doesn't evaluate at every step ...! >>> >>> this is the problem that Hauke is talking about: since we nest by >>> value, tmp is stored in the expression of tmp + A1, so sizeof(tmp+A1) >>> = big, so does (tmp+A1)+A2, etc. I did not check but I think that the >>> way it works. >>> >>> on the other hand if you write: >>> >>> (A*B).eval() + A1 + A2 + A3 + A4 + A5 >>> >>> then it is fine fine because the temporary is explicitly created on >>> the stack and stored by reference by the binary expressions... >> >> Ah OK and can't we make an exception to the rule that we nest >> expressions by value? Couldn't we say: we nest by value EXCEPT plain >> matrices which we nest by reference? Then nesting by value an >> expression referring it would just copy a reference. > > we cannot store implicit temporaries by reference, it has to live > throughout the expression, and so it has to be stored by the returned > expression. ok, some day I should learn to be able to decide that myself... :( then I'm starting to understand how the change that you are proposing here is an inevitable consequence of the new nest-by-value design. I'm crossing fingers that it turns out to be a change for the better! (that is, not too bad compilation times). Benoit > > gael. > >> >> I usually say stupid things when I'm talking about references and >> lifetime of temporaries :) >> >> Benoit >> >> >> >>> >>> gael >>> >>> >>>> Benoit >>>> >>>>> >>>>> gael >>>>> >>>>>> >>>>>> Am I missing something? I am especially afraid of being missing >>>>>> something about the blas_traits and how you implemented that stuff --- >>>>>> you know better than me. >>>>>> >>>>>> Benoit >>>>>> >>>>>> >>>>>> >>>>>>> Such an analyzer/evaluator would look like the current ei_blas_traits... >>>>>>> Some examples of what could be done with such an approach: >>>>>>> >>>>>>> (A + B).block() => (A.block() + B.block()) >>>>>>> >>>>>>> E.noalias() += A*B + C*D; >>>>>>> >>>>>>> => >>>>>>> >>>>>>> E.noalias() += A*B; >>>>>>> E.noalias() += C*D; >>>>>>> >>>>>>> This also offers more parallelization opportunities. >>>>>>> >>>>>>> Sounds good, but of course I'm really scared about compilation times... This >>>>>>> is why I did not talk that much about that idea so far. >>>>>>> >>>>>>> gael. >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 4, 2010 at 2:35 PM, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> While looking into the "performance degradation" issue from the forum >>>>>>>> I found out that it is due to temporaries - as Benoit already guessed. >>>>>>>> >>>>>>>> I am a little bit afraid, that what I once proposed, namely copying >>>>>>>> expressions by value, is now backfiring. The reason is that initially >>>>>>>> I assumed expressions to be tiny little objects with close to no copy >>>>>>>> costs. The issue is related to those expressions holding temporaries. >>>>>>>> Copying them (e.g. a product expression) means copying all the data >>>>>>>> including the temporary and that will happen as many times as we nest >>>>>>>> expressions. >>>>>>>> >>>>>>>> The only solution I can think about at the moment is the >>>>>>>> specialization of ei_nested for those types and to go back to nesting >>>>>>>> by reference for these heavy weight guys. >>>>>>>> >>>>>>>> - Hauke >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >

**Follow-Ups**:**Re: [eigen] nesting***From:*Gael Guennebaud

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

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

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

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

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

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] const Static Vector/Matrix howto** - Next by Date:
**Re: [eigen] const Static Vector/Matrix howto** - Previous by thread:
**Re: [eigen] nesting** - Next by thread:
**Re: [eigen] nesting**

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