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

[Billy Araujo <billyaraujo@xxxxxxxxx>]

Blaze looks nice and easy to use but I will continue to use Eigen since the data compression aspect is very important to me.

I have read some things about _expression_ templates and would like to apply this to a pde solver using Eigen as base math library. My problem is how to vectorize for example:

ddt(T) + div(T) = 0

instead of creating two matrices. But the operations inside the matrix creation is complex. Depends on numerical method, stencil, etc.

Is anyone working on something similar?

On Tue, Aug 28, 2012 at 3:47 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

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