|Re: [eigen] Why no LU::solveInPlace()?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Why no LU::solveInPlace()?
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 3 Sep 2010 16:58:53 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=1EZGgHzSNhFcUhSfSwGC8Ah16I0UTz2CnDUKZTGVKvg=; b=sA6W2PyAHYuHtJvfVoay2ULsvLIOi4wu95yFchZcjmScE7vy1lLQkXDkPbHg1J4mXJ td5veH+5v5Ad7y/w4cN/kkyZwKYilrZaiQ/cTSn2AKiJD481ILxWY8OHbZRPQ/pAoISP CJQcogHmOQqUDjoErkTLh+bcYrPZ5VpHYMuGA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=xSZ8vwx5uTcVtXOCpfazm4ugu4HoN3BGkztpb20hTjEiHHqwXxz8bxgXPGZvknjtmn s8jPISrFzRZunkrTWfau+6ymCd+DkAxaLx23Hp5652gR+IlxFX2ilA9v8cE1n3HSBfGd u+B2Emo6FCLxhhxmDrd4eLBDjxKJkQrOA/WAc=
On Fri, Sep 3, 2010 at 4:50 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/9/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> On Fri, Sep 3, 2010 at 4:33 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> B.foo().bar().long().expression() = A.solve(B.foo().bar().long().expression());
>>> Wait, there are 2 more problems here that I didn't anticipate before.
>>> The first problem is that B.foo() will return a new (lightweight)
>>> expression object everytime, so pointer comparisons will fail.
>> no no, I compare the data pointers (just like for debugging
>> transpose), not the addresses of the temporary expressions. I guess
>> this also answer your second concern ?
> ooooh right, thanks.
in case you' want to look for it, let me also precise that currently
this optimization - yes this "if" is an optimization - is done at the
level of the Permutation product.
For LLT solving (Ax=b), we start by doing:
x = b;
and then do inplace triangular solving,
so ideally this copy should be avoided at the level of operator=
itself, but I feel you won't agree me putting a if there though again
this would be an optimization...
The if would be an overhead if and only if the types matches but the
objects are not the same as in:
Matrix2d A, B;
A = B;
or (more worrying because more realistic):
a = foo();
I will check how the compiler deal with that and let you know....
>>> The second problem is that just taking a pointer to an expression
>>> object could easily prevent the compiler from "optimizing away" this
>>> object. I know we are already doing that in transpose() aliasing
>>> detection but that is just in debug mode, right? Here we're now
>>> talking about adding that also in non-debug mode and that could be a
>>> bigger issue. Although I guess that the cost of constructing the
>>> expression is totally negligible in this particular case (solving
>>> being expensive enough) I thought that was worth bringing up. In the
>>> case of complex enough expressions and small fixed sizes, this could
>>> easily become non-negligible.