Re: [eigen] about the semantic of MaxRows, MaxCols |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] about the semantic of MaxRows, MaxCols
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 3 Mar 2010 07:59:14 -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=MGZib8KewgKT1/m0zsL7ymjDCroFNub1MZRTBR+kjC8=; b=slYPZTHfiqwypN9L/W5I2LcHNvhF+m4VRHbLtN9KE3EMgw5HgmtO2PSJole28cfKRb rjaXofao2roOIW2XEcw8PlI9Pt40Q/n+ax5Q4SWnDZcz6JxAjbvE6qdKqtGNnRC34XQR k9JmYGQ67hknidWMIWkirA3/DDDA83xqNoRhM=
- 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=A5dMvHV+LyvAMc4cDy6iGh4WPDNLTv+GOp1+zBt3IAugA0vtMReeLHrNkRO4S0FmGs h8so/QCz6rweRdMCk10pIfUUM/9FmR+TjguBC1zzrSnEVcYSqCwGPgQYxrzPtqFHtNdy 4VyUExFsEhhVFkAgwbj9K5giBhZUTVBxA9IQ4=
2010/3/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
> Hi,
>
> A recent change of mine about matrices having different max sizes and actual
> sizes broke lu kernel computation. The reason is that I thought that in the
> following example:
>
> Matrix<float,3,3,0,4,4> m;
> m << 0, 3, 6,
> 1, 4, 7,
> 2, 5, 8;
>
> the data were organized as follow:
>
> 0 1 2 x 3 4 5 x 6 7 8 x x x x x
>
> i.e., Matrix<float,3,3,0,4,4> was like a 3x3 block of a 4x4 matrix. However,
> currently, the 3x3 floats are taken from the 9 first ones of the 16
> statically allocated buffer:
>
> 0 1 2 4 4 5 6 7 8 x x x x x x x
>
> i.e., Matrix<float,3,3,0,4,4> is really like a Matrix<float,3,3>.
>
> So the question is shall we stick with the current behavior ? or shall we
> adopt what I thought it was ? Let's enumerate the pros and cons for the
> change:
> pros:
> * potentially allows for more vectorization since, e.g., it allows to
> align all the columns of a Matrix<float,3,Dynamic> using
> Matrix<float,3,Dynamic,0,4,Dynamic>
> cons:
> * this is a change so more work to do and potentially new bugs ;)
> * such matrices lost the linear access flags
This complexifies a lot a concept that was, so far, very simple
(indeed the Max dimensions only have an effect for the allocation of
the array, and no effect at all on the data layout inside of that
array).
So it needs to be justified by a big benefit and one should also check
if there's a simpler way to allow the same...
Benefit check: how good is it to have aligned columns in a
column-major matrix? It allows to vectorize certain matrix products
although it requires special care as we now have uninitialized scalars
coming into play...
On the other hand we lost he LinearAccess bit as you mention, and,
independently of that, the vectorization of linear operations is now,
at best, only 3/4 as efficient.
If we are certain that the user wants that then of course it's his
responsibility, but here, i could imagine an algorithm with
meta-unrollers producing a Matrix<float,3,3,0,4,4> from an initial
Matrix4f....
So I have the impression that if we want to offer the possibility of
this kind of matrices, another API is needed. Could be a new Matrix
option AlignInner...
Benoit
>
> what do you think ?
>
> gael
>