Re: [eigen] Eigen 2 to Eigen 3 performance regressions with mapped matrices

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

I would be in favor of always assuming that fixed-size products are
small so always use "lazyProduct" in the fixed-size case, without even
a runtime size check.

This would also allow to really guarantee that we never malloc  on
fixed-size computations...

We could still provide a separate way to do cache-friendly products on
fixed-size matrices, if there really is demand for that. For starters,
people can always Map as dynamic-size.

Cheers,
Benoit

2012/1/12 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Hi,
>
> well first you should really use 1 instead of Dynamic for the vectors
> such that gemv like operations are called (instead of gemm like).
>
> Then, the main difference with Eigen2, is that we don't check anymore
> the sizes at runtime to fallback to a naive product implementation if
> the objects are too small. Again, you can still enforce the naive
> product with .lazyProduct if you know that's best for you.
>
> That said, I still plan to add such runtime tests to pick the right
> algorithm. I think there is still room for designing even better
> product algorithms for such small matrices and vectors. However I
> observed the performance of a "naive" product algorithm depends a lot
> on the architecture and compiler for small objects, so the choice of
> the thresholds is rather difficult.
>
> I'll add an entry in our bug tracker.
>
> gael
>
> On Wed, Jan 11, 2012 at 4:58 AM, Keir Mierle <mierle@xxxxxxxxx> wrote:
>> I've attached a microbenchmark that is similar in spirit to what we are
>> doing with Eigen, that illustrates slowdown from Eigen 2 to Eigen 3. In
>> particular, the benchmark does y += A*x, for A, x, y mapped unaligned
>> dynamic but small dimension matrices. It could be that I have not chosen
>> appropriate compiler flags. I am seeing performance 2x to 3x worse. Take a
>> look at the header comments in the attached benchmark for more numbers.
>>
>> Keir
>
>