mirror of
https://gitlab.com/libeigen/eigen.git
synced 2025-10-18 02:51:30 +08:00
Avoid phrase "static allocation" for local storage on stack (bug #615).
(transplanted from 4e6d746514d3b7ef31cf4cd1ac5b48eb0e3cbe9e )
This commit is contained in:
parent
c7ba7f59d6
commit
560877016a
@ -98,8 +98,8 @@ Matrix3f a;
|
||||
MatrixXf b;
|
||||
\endcode
|
||||
Here,
|
||||
\li \c a is a 3x3 matrix, with a static float[9] array of uninitialized coefficients,
|
||||
\li \c b is a dynamic-size matrix whose size is currently 0x0, and whose array of
|
||||
\li \c a is a 3-by-3 matrix, with a plain float[9] array of uninitialized coefficients,
|
||||
\li \c b is a dynamic-size matrix whose size is currently 0-by-0, and whose array of
|
||||
coefficients hasn't yet been allocated at all.
|
||||
|
||||
Constructors taking sizes are also available. For matrices, the number of rows is always passed first.
|
||||
@ -216,7 +216,7 @@ The simple answer is: use fixed
|
||||
sizes for very small sizes where you can, and use dynamic sizes for larger sizes or where you have to. For small sizes,
|
||||
especially for sizes smaller than (roughly) 16, using fixed sizes is hugely beneficial
|
||||
to performance, as it allows Eigen to avoid dynamic memory allocation and to unroll
|
||||
loops. Internally, a fixed-size Eigen matrix is just a plain static array, i.e. doing
|
||||
loops. Internally, a fixed-size Eigen matrix is just a plain array, i.e. doing
|
||||
\code Matrix4f mymatrix; \endcode
|
||||
really amounts to just doing
|
||||
\code float mymatrix[16]; \endcode
|
||||
@ -231,8 +231,9 @@ member variables.
|
||||
The limitation of using fixed sizes, of course, is that this is only possible
|
||||
when you know the sizes at compile time. Also, for large enough sizes, say for sizes
|
||||
greater than (roughly) 32, the performance benefit of using fixed sizes becomes negligible.
|
||||
Worse, trying to create a very large matrix using fixed sizes could result in a stack overflow,
|
||||
since Eigen will try to allocate the array as a static array, which by default goes on the stack.
|
||||
Worse, trying to create a very large matrix using fixed sizes inside a function could result in a
|
||||
stack overflow, since Eigen will try to allocate the array automatically as a local variable, and
|
||||
this is normally done on the stack.
|
||||
Finally, depending on circumstances, Eigen can also be more aggressive trying to vectorize
|
||||
(use SIMD instructions) when dynamic sizes are used, see \ref TopicVectorization "Vectorization".
|
||||
|
||||
|
@ -55,7 +55,7 @@ All combinations are allowed: you can have a matrix with a fixed number of rows
|
||||
Matrix<double, 6, Dynamic> // Dynamic number of columns (heap allocation)
|
||||
Matrix<double, Dynamic, 2> // Dynamic number of rows (heap allocation)
|
||||
Matrix<double, Dynamic, Dynamic, RowMajor> // Fully dynamic, row major (heap allocation)
|
||||
Matrix<double, 13, 3> // Fully fixed (static allocation)
|
||||
Matrix<double, 13, 3> // Fully fixed (usually allocated on stack)
|
||||
\endcode
|
||||
|
||||
In most cases, you can simply use one of the convenience typedefs for \ref matrixtypedefs "matrices" and \ref arraytypedefs "arrays". Some examples:
|
||||
|
Loading…
x
Reference in New Issue
Block a user