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