| Re: [eigen] Qt's container support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Qt's container support
- From: Keir Mierle <mierle@xxxxxxxxx>
- Date: Tue, 20 Jan 2009 08:09:35 -0800
- 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=Az7UcrNZU834+ZqA6ZPr3C6T1mritYMNGW6EPstwGl0=; b=ZEsJ6oJ9RJAp6w2SF1V4P97d9A/XVRFMbiDIK5whJsiQ40f6BzGquVUXWjB+nYbt2W CkkWc9IDVEr7y9wUqEcBkR2jsKryZk1AxQT2Q8xiWSpkdoZr9nlBJdac6PQkhITc8X5t UnlnLhf158hitfPW/hsRz2Rhce9LIXR2dkIBs=
- 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=jv9BzHUNavivoerMXpy48ZElQCEQm9x2Kaig+m7hLNwEV46B/gu/Tgz1p9h7a3HMci T9eOPNkD1azzaZIPtCWBgrkRA8Rktt20WSPlkuEWcAaTJjNR/mEZeuSUkaGG8LP40Oqt eUjzH7vicgR6F3sejsi1SEjhcoS+6YHc6cE14=
On Tue, Jan 20, 2009 at 8:03 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/1/20 Keir Mierle <mierle@xxxxxxxxx>:
>> What is wrong with (a)? I'd like to have this anyway.
>
> In my understanding the main problem with (a) was that it would
> require operator= to start with an if() to check if the matrix is
> already initialized (so runtime overhead).
>
> Perhaps this argument isn't convincing: dynamic-size matrices involve
> runtime branching anyway eveytime you have to loop over their
> coefficients, so this if() is going to be negligible.
Exactly. Also, I believe that in some cases GCC can prove that a
matrix is uninitialized even for dynamic sized matrices and skip the
if, provided operator= is inlined. This will require some
investigation, but my understanding is that the scalar promotion of
aggregates optimization phase will expose this (scalar promotion of
aggregates breaks structures up into individual basic types, exposing
many optimization opportunities).
> It's true that this aspect of our API is one of the things that's
> causing the most trouble to users. I'm open to reconsidering it. But
> first: is there another reason for the current behavior that i
> forgot...?
>
> Benoit
>
>
>