Eigen
3.2.90 (mercurial changeset dc4fdd3e22cf)

Executive summary: Eigen has intelligent compiletime mechanisms to enable lazy evaluation and removing temporaries where appropriate. It will handle aliasing automatically in most cases, for example with matrix products. The automatic behavior can be overridden manually by using the MatrixBase::eval() and MatrixBase::noalias() methods.
When you write a line of code involving a complex expression such as
Eigen determines automatically, for each subexpression, whether to evaluate it into a temporary variable. Indeed, in certain cases it is better to evaluate immediately a subexpression into a temporary variable, while in other cases it is better to avoid that.
A traditional math library without expression templates always evaluates all subexpressions into temporaries. So with this code,
a traditional library would evaluate vec2
+ vec3 into a temporary vec4
and then copy vec4
into vec1
. This is of course inefficient: the arrays are traversed twice, so there are a lot of useless load/store operations.
Expressiontemplatesbased libraries can avoid evaluating subexpressions into temporaries, which in many cases results in large speed improvements. This is called lazy evaluation as an expression is getting evaluated as late as possible, instead of immediately. However, most other expressiontemplatesbased libraries always choose lazy evaluation. There are two problems with that: first, lazy evaluation is not always a good choice for performance; second, lazy evaluation can be very dangerous, for example with matrix products: doing matrix = matrix*matrix
gives a wrong result if the matrix product is lazyevaluated, because of the way matrix product works.
For these reasons, Eigen has intelligent compiletime mechanisms to determine automatically when to use lazy evaluation, and when on the contrary it should evaluate immediately into a temporary variable.
So in the basic example,
Eigen chooses lazy evaluation. Thus the arrays are traversed only once, producing optimized code. If you really want to force immediate evaluation, use eval():
Here is now a more involved example:
Eigen chooses lazy evaluation at every stage in that example, which is clearly the correct choice. In fact, lazy evaluation is the "default choice" and Eigen will choose it except in a few circumstances.
The first circumstance in which Eigen chooses immediate evaluation, is when it sees an assignment a = b;
and the expression b
has the evaluatebeforeassigning flag. The most important example of such an expression is the matrix product expression. For example, when you do
Eigen first evaluates matrix * matrix
into a temporary matrix, and then copies it into the original matrix
. This guarantees a correct result as we saw above that lazy evaluation gives wrong results with matrix products. It also doesn't cost much, as the cost of the matrix product itself is much higher.
What if you know that the result does no alias the operand of the product and want to force lazy evaluation? Then use .noalias() instead. Here is an example:
Here, since we know that matrix2 is not the same matrix as matrix1, we know that lazy evaluation is not dangerous, so we may force lazy evaluation. Concretely, the effect of noalias() here is to bypass the evaluatebeforeassigning flag.
The second circumstance in which Eigen chooses immediate evaluation, is when it sees a nested expression such as a + b
where b
is already an expression having the evaluatebeforenesting flag. Again, the most important example of such an expression is the matrix product expression. For example, when you do
the product matrix3 * matrix4
gets evaluated immediately into a temporary matrix. Indeed, experiments showed that it is often beneficial for performance to evaluate immediately matrix products when they are nested into bigger expressions.
The third circumstance in which Eigen chooses immediate evaluation, is when its cost model shows that the total cost of an operation is reduced if a subexpression gets evaluated into a temporary. Indeed, in certain cases, an intermediate result is sufficiently costly to compute and is reused sufficiently many times, that is worth "caching". Here is an example:
Here, provided the matrices have at least 2 rows and 2 columns, each coefficienct of the expression matrix3 + matrix4
is going to be used several times in the matrix product. Instead of computing the sum everytime, it is much better to compute it once and store it in a temporary variable. Eigen understands this and evaluates matrix3 + matrix4
into a temporary variable before evaluating the product.