Re: [eigen] nesting

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

arf indeed, anytime an _expression_ is evaluated at nesting time, a matrix gets stored by value and potentially it can be copied multiple times... I think this is one more argument in favor of a top-down evaluation mechanism. In short, the idea behind this is:

1 - remove all evaluation at nesting time, and simply build the complete _expression_ tree
2 - at evaluation time, you send your complete _expression_ to a template evaluator which will recursively analyze your _expression_ from the top, reorder some subexpression, and evaluate some sub expressions when needed. Such an analyzer/evaluator would look like the current ei_blas_traits... Some examples of what could be done with such an approach:

(A + B).block() => (A.block() + B.block())

E.noalias() += A*B + C*D;

=> 

E.noalias() += A*B;
E.noalias() += C*D;

This also offers more parallelization opportunities. 

Sounds good, but of course I'm really scared about compilation times.... This is why I did not talk that much about that idea so far.

gael.

On Thu, Feb 4, 2010 at 2:35 PM, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> wrote:

Hi,

While looking into the "performance degradation" issue from the forum
I found out that it is due to temporaries - as Benoit already guessed.

I am a little bit afraid, that what I once proposed, namely copying
expressions by value, is now backfiring. The reason is that initially
I assumed expressions to be tiny little objects with close to no copy
costs. The issue is related to those expressions holding temporaries.
Copying them (e.g. a product _expression_) means copying all the data
including the temporary and that will happen as many times as we nest
expressions.

The only solution I can think about at the moment is the
specialization of ei_nested for those types and to go back to nesting
by reference for these heavy weight guys.

- Hauke