You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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
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!
The text was updated successfully, but these errors were encountered: