|Re: [eigen] about the semantic of MaxRows, MaxCols|
[ Thread 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 08:18:21 -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=PudfYLjyf6OQt3S/Kx0//zGf5gLld9IbldBiGjEyYNo=; b=ZyVpovlch8oDxE4mN9EKOYV1ZtUNiBFXx1kc+6MfjtfVr4LNaYGT1Ru8GJ6zsZ0Kjj uWQ7TxTOSY00yv/L3rhMqgD4EKmWcVcMDSUvC2WUTZ9BXV+3PsT/bHaUHwjm6Xt2Ln0h KrmM/AayQNq+V/ys255PAJO7q8260Q7248FoU=
- 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=w5Cr1EDDV6hx9idN7PuqnY4+0uh4RUiey0hm4OPwxkmT91hIbhn1lJWXTw5dUWn7b3 8RJIN05pIFPivYzP32+25mYkFJwOC4oUgg4SKSdMiAm6GNwm8Poaz856yyKd9v6jZZkL xAmfbWBaGrxgN299Ii69YKNV2pwgAoPJa43H4=
2010/3/3 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/3/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> 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
>> * potentially allows for more vectorization since, e.g., it allows to
>> align all the columns of a Matrix<float,3,Dynamic> using
>> * 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
> 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
> 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...
Big argument in favor of keeping the default as-is and possibly adding
an AlignInner option later: such a change will be both API and ABI
compatible. So it can be done at any later date. By contrast, in your
initial proposal, we must get that done right now.
>> what do you think ?