Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confused about Eigen Colum-Major/Row-Major and ouster::LidarScan::Points #557

Open
vebjornjr opened this issue Oct 9, 2023 · 1 comment
Labels
question Further information is requested

Comments

@vebjornjr
Copy link

Hello!

We are confused about Eigen Storage order and the points returned from your SDK. Hope you can help us with our understanding.

As we understand, the default storage order in Eigen is Column-Major (which means data in each column is layed out after each other in memory).
https://en.wikipedia.org/wiki/Row-_and_column-major_order
For cache locality, we assumed it would make most sense to have the XYZ values of each point after each other in memory.

So with Column-Major storage we would expect the points returned from your SDK to be organized as 3 x N. 3 rows and dynamic numbers of columns. Eigen::Array<double, 3, Eigen::Dynamic> (or Eigen::Matrix).

However, the LidarScan::Points type in your SDK is the opposite. It is an array/matrix with dynamic number of rows and 3 columns. Eigen::Array<double, Eigen::Dynamic, 3>. We do not see that you force RowMajor on that specific type or in your project as a whole.

When we access the X, Y and Z values of a single point with your type we expect to access memory in three different places instead of three accesses to adjacent memory.

Is there any reason behind using Column-Major storage and dynamic number of rows? Or have we simply confused ourselves?

Thank you!

@vebjornjr vebjornjr added the question Further information is requested label Oct 9, 2023
@Samahu
Copy link
Collaborator

Samahu commented Oct 9, 2023

You conclusion about the order used to represent the Point array is correct. I don't personally know the reasoning on why ColumnMajor was used instead of RowMajor for the list of points. I could see certain operations could benefit from it and others don't for example, say you want to filter points that are higher or lower than a certain threshold on any of the three axis. But generally speaking if you want to read x, y, z values together then RowMajor yields better performance.

You could obtain the RowMajor from ColumnMajor using the transpose() operation. This of course will incur some additional time and storage to compute but the transposed array will be more cache friendly.

We could probably explore adding an option to readily return the Points array in either order. @twslankard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants