This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 1090 - Unable to use .norm() on block expressions.
Summary: Unable to use .norm() on block expressions.
Status: RESOLVED FIXED
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - expression templates (show other bugs)
Version: 3.2
Hardware: All Windows
: Normal Compilation Problem
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-16 15:54 UTC by ipolok
Modified: 2019-12-04 15:03 UTC (History)
3 users (show)



Attachments

Description ipolok 2015-10-16 15:54:47 UTC
The following snippet of code:

const int n_columns = 600;
double f_diag_partial_sum - 0;
enum { n_stripe = 6; };
for(int i = 0; i < n_columns; i += n_stripe) {
	Eigen::MatrixXd t_my_stripe(n_columns, n_stripe);
	// [fill the matrix with data]
	// calculate a stripe of the marginals at a time

	f_diag_partial_sum += t_my_stripe.template block<n_stripe, n_stripe>(i, 0).eval().squaredNorm();
	// calculate norm
}

This code won't work without the .eval() bit. This is a shame as norm() and squaredNorm() are (at least in my view) very simple reductions and calculating a temporary completely kills performance. I think this should be quite easy to fix.
Comment 1 Gael Guennebaud 2015-10-21 16:36:48 UTC
Indeed, there is an issue with compile-time sized blocks. The following works too:

t_my_stripe.block(i, 0, n_stripe, n_stripe);

fix asap.
Comment 2 Gael Guennebaud 2015-10-21 16:56:31 UTC
hm, it's even more tricky: the issue occurs for block sizes of 6 only. It is trying to do both slice-vectorization and unrolling while this case is not supported...
Comment 3 ipolok 2015-10-21 17:12:48 UTC
Oh, pretty please, do optimize the 6x6 cases. 6x6 happens to be an important case in computer vision and robotics since a 3D pose can be represented in 6 dimensions (x, y, z, a, b, c) where a, b, c can be axis-angle, the imaginary part of a quaternion or if you are extreme, yaw pitch roll. This corresponds to the SE(3) group.

7x7 is also kind of important when scale is added - the Sim(3) group. I guess with 7 being a prime, it is hard to vectorize reasonably.

I'll buy your team pizza & beer / prostitutes / star wars memorabilia if you optimizes for the 6x6 cases :). We really use them a lot.
Comment 4 ipolok 2015-10-21 17:13:35 UTC
I forgot to mention that 6D is a pose and 6x6 is a pose-pose derivative.
Comment 5 Gael Guennebaud 2015-10-21 19:07:59 UTC
Fixed:
https://bitbucket.org/eigen/eigen/commits/f5273e0e
https://bitbucket.org/eigen/eigen/commits/8cadbb0

Regarding optimizations, it is already the case for 6x6 matrices. However, in your case, since you accessing to a 6x6 subblock, we cannot figure out at compile time that everything is well aligned. Using a rowmajor storage like:

Matrix<double,Dynamic,6,RowMajor>

and accessing it as .middleRows<6>(i) will help.
Comment 6 Nobody 2019-12-04 15:03:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1090.

Note You need to log in before you can comment on or make changes to this bug.