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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

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.

gael


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] http://www.netlib.org/na-digest-html/12/v12n35.html#1
>> [2] http://dx.doi.org/10.1137/110830125
>>
>>