On Tue, Aug 28, 2012 at 4:39 PM, Gael Guennebaud
> On Tue, Aug 28, 2012 at 4:24 PM, Rhys Ulerich <rhys.ulerich@xxxxxxxxx
>> Hi all,
>> I noticed Blaze on the NA Digest list  on the NA Digest list, read
> I noticed it too.
>> the associated paper , 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
>> 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.
>>  http://www.netlib.org/na-digest-html/12/v12n35.html#1
>>  http://dx.doi.org/10.1137/110830125