Re: [eigen] Comparing notes on work by Igleberger et al. 2012

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

On 28.08.2012 16:39, Gael Guennebaud wrote:
> On Tue, Aug 28, 2012 at 4:24 PM, Rhys Ulerich <rhys.ulerich@xxxxxxxxx> wrote:
> > [...]
>
> Partly. Blaze is also able to exploit AVX instruction (so a
> theoretical x2 compared to SSE), however Blaze suffers from a HUGE
> shortcoming: data are assumed to be perfectly aligned, including
> inside a matrix. For instance, a row-major matrix is padded with empty
> space such that each row is aligned. The extra space *must* be filled
> with zeros and nothing else because they are exploited during some
> computations... As a consequence, Blaze does not has any notion of
> sub-matrices or the like, cannot map external data, etc. One cannot
> even write a LU decomposition on top of Blaze. In other word, it is
> not usable at all. This is also unfair regarding the benchmarks
> because they are comparing Blaze with perfectly aligned matrices to
> Eigen or MKL with packed and unaligned matrices.

Actually, it would be nice to optionally support padding in Eigen as 
well, sth like padding to the next multiply of packet-size or so.
This would also have the benefit that e.g. col(i) expressions can 
actually return an aligned map.

As for the API, one could use the Rows/ColsAtCompileTime template 
parameters, with -2, -4 meaning round up to next multiply of 2, 4, etc. 
This would even be consistent with current Dynamic=-1.
A problem, however, would be if either of them is a positive multiply of 
2 or 4. At the moment, I guess, there will not be any padding, so 
storing a (dynamic) 3x3 matrix inside a Matrix<T,-1,-1,*,3,4> or 
Matrix<T,-1,-1,*,4,3> does exactly the same, right? (Ideally, I would 
like the latter to pad each column. Maybe adding another options flag 
could do the trick)

Currently, Eigen already has an AlignedVector3 class, which essentially 
does padding but just for one special case (which could then be 
simplified to Matrix<T, 3, 1, *, 4, 1>).

> > 2) Blaze shows faster performance on A*B*v for A and B matrices
> > because they don't honor order of operations and their expression
> > templates treat it as A*(B*v).  This is moot as I can simply write
> > A*(B*v) in Eigen.
>
> Exactly, though we plane to do the same (and more) once the evaluators
> finalized.

Hm, I wouldn't think it's a good idea to optimize this automatically 
without warnings/special flags. I can't think of an example right now 
where it would harm (of course, if v is a matrix as well, it's easy to 
find examples where the first is better than the second), but I would 
like to be able to distinguish between (A*B)*v and A*(B*v).


And a completely different note, has anyone checked how they do their 
"automatic alias detection"? If, as Gael says, they don't support 
sub-matrices, do they just compare the data pointers, or can they 
actually decide it at compile time somehow?
I wouldn't see how they can do it with methods like (Eigen syntax):

void aliastest(VectorXd& res, const VectorXd &x){
	res = {some complex expression with x};
}



Christoph

--
----------------------------------------------
Dipl.-Inf. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------