This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Row/Column Major

Tags: None
(comma "," separated)
jorisp
Registered Member
Posts
2
Karma
0

Row/Column Major

Tue Apr 14, 2015 9:04 pm
Our C++ code is tightly coupled to embedded python, where we may want to expose the matrices (as in C++) as numpy ndarrays. In order to avoid reflection (which is comparatively costly due to the cache misses), we'd therefore prefer to always have all the data in row major form (both in C++ and in python) - as that is numpy's favoured order.

We're looking for a linear algebra library that will allow us to do the C++ side of what we need (matrix-vec prod, eigenvalue decomposition, ...).
We can't do this with Lapack (the FORTRAN lib expects col-major), so are considering to move to Eigen. What I'd like to know is if either of the row or column major forms are more inherently performant in Eigen (e.g., maybe some algorithms first convert a row-major into a column major prior to being able to do eigenvalue decomposition) - or whether both are pretty much identical.

Thanks!
User avatar
ggael
Moderator
Posts
3447
Karma
19
OS

Re: Row/Column Major  Topic is solved

Wed Apr 15, 2015 8:00 am
You can easily work with row-major matrices in Eigen by using the Matrix's Option template parameter, e.g.:

Matrix<double,Dynamic,Dynamic,RowMajor>

Matrix and vector products work very well with either column/row major matrices. However, most matrix decompositions use column-major matrices for their internal representation because they typically eliminate one column at a time, and for this reason you won't find efficient decomposition implementation working on row-major matrices without implicit transposition. Nevertheless, a matrix transposition is really cheap compared to a matrix decomposition, so I would not bother too much on that aspect. What is really important is that products perform well on both storage order.
jorisp
Registered Member
Posts
2
Karma
0

Re: Row/Column Major

Wed Apr 15, 2015 6:04 pm
Cool, thanks - that does sound promising.

Just to clarify, the main motivation for our desire to work with row-major is because we frequently transport back and forth to python & numpy. Column-major support in numpy is not quite as comprehensive and the time spent doing reflections (normally once when the data is passed to python and once when it comes back) is actually a sizable part of the total computation time, worth optimising away.


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]