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

[ Thread Index | Date Index | More Archives ]

Another funny fact for a so called "smart expression template
library": they have 24 copy-pasted implementations of dense
matrix*vector products:

  3 for =, +=, and -=
* 2 for row/column major
* 2 for a scaled or unscaled product (e.g., 2*A*v vs A*v)
* 2 for vectorized, non vectorized versions

As I said, none of the vectorized version is able to handle non
perfectly aligned and padded matrices. Eigen has only 2 variants for
row versus column major.


On Tue, Aug 28, 2012 at 4:39 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> On Tue, Aug 28, 2012 at 4:24 PM, Rhys Ulerich <rhys.ulerich@xxxxxxxxx> wrote:
>> Hi all,
>> I noticed Blaze on the NA Digest list [1] on the NA Digest list, read
> I noticed it too.
>> the associated paper [2], and wondered if I could compare my takeaway
>> knowledge with anyone else familiar with both Blaze and Eigen:
>> 1) At the time of writing, Blaze shows faster dgemm than Eigen3
>> because they simply defer to the MKL.  This is moot as Eigen 3.1
>> allows use of the MKL as well.
> 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.
>> 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.
>> 3) Blaze does show some convincingly better results for mixed
>> dense/sparse operations.
> Indeed, compressed sparse representations offers very little room for
> optimizing basic operations.
> gael.
>> Thanks,
>> Rhys
>> [1]
>> [2]

Mail converted by MHonArc 2.6.19+