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

[ Thread Index | Date Index | More Archives ]

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

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};


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

Tel: +49 (421) 218-64252

Mail converted by MHonArc 2.6.19+