Hi!

I have to solve for all eigenvalues of a real symmetric matrix. I found a post in this forum which asserts rather bad performance of eigen in comparison to blas implementations. Is this still the case? If yes, is it possible to assemble a sparse matrix with the eigen-interface and pass over a pointer to the array storing the csr-matrix somehow to lapack? Just curious about that, since it appears not a very convenient to do that directly via lapack/blas - at least for a lapack/blas beginner like me.

Thanks a lot in advance,

Sebastian

For dense symmetric matrices, now Eigen has quite good performances.

But here you are interested in sparse matrices that is very different. So far we don't provide any support for that. So you have to use another lib to do the actual decomposition. BLAS/LAPACK won't help you here because they are for dense objects only. Nevertheless you can still assemble your SparseMatrix using Eigen's API, and then send it the other library. Eigen uses a standard storage format so that should not be a problem.

A popular lib for that is SLEPc: http://www.grycap.upv.es/slepc.

Hi!

What does "now" mean? Starting from which version of Eigen is this case to be considered fast? Or are you referring to the development version of Eigen?

I read of Slepc, but it appears to be quite heavy to use from C++.

Sebastian

now = the devel branch.

Yes unfortunately all existing sparse packages that I know are far to be trivial to use. One of the goal of the Eigen's sparse module is exactly to provide a simple an unified API to all that very good but very low level libs...

Maybe this survey can help you in your choice:

http://www.mathadonf.com/spip.php?page= ... article=51

Thanks!

I just found FLENS which appears to be a neat wrapper C++ to BLAS. Then my matrices will be dense, but well, I gotta live with that for now. I anyway always want all EV, which seemes to be difficult for SlepC once I tried it a while ago.

An alternative would be the Eigen development branch, but how stable to you consider the API? Is there a possibility to easily backport the required code?

Sebastian

Hi,

I wonder if "I anyway always want all EV" do not heavily imply to have less then, let's say 100 degrees of freedom?

If this implification hold, what are the performance differences of dense vs. sparse? Maybe a dense lib is sufficient.

And a last question: Is it ok to assume, that Eigen (devel-branch) competes well with flens?

... or I'm totally wrong here.

Cheers
Frank

To help you in your choice, on my computer Eigen takes about 270ms to compute all eigenvalues/vectors of a symmetric random matrix (using float).

Also I think that switching to sparse algorithms really makes sens if you have matrices bigger than 1000^2 or perhaps if your matrices are very very sparse...

For the stability of the devel branch: it is more stable than the 2.0 branch from a numerical point of view. What could be a little instable is the API, so if you take a snapshot and stick with it, you should be fine, and even more comfortable than with the 2.0 branch.

To help you in your choice, on my computer Eigen takes about 270ms to compute all eigenvalues/vectors of a symmetric random matrix (using float).

It would even more with his choice if you said the matrix size

bjacob wrote:

To help you in your choice, on my computer Eigen takes about 270ms to compute all eigenvalues/vectors of a symmetric random matrix (using float).

It would even more with his choice if you said the matrix size

arf, I've been too fast, it's for a 600 x 600 matrix !

Hi!

When do you expect Sparse matrix EV solvers to be in Eigen, there are plans for it, right?

My matrices are currently 500x500 and I want to go at least to 10^3 degrees of freedom. On average I have 15*N non-zero entries where N is the number of the variables, so a sparse library would be right, I guess.

Sebastian

sweber wrote:Hi!

When do you expect Sparse matrix EV solvers to be in Eigen, there are plans for it, right?

yes but not soon.

My matrices are currently 500x500 and I want to go at least to 10^3 degrees of freedom. On average I have 15*N non-zero entries where N is the number of the variables, so a sparse library would be right, I guess.

actually, Frank was right. Since you need all eigenvectors, and that the eigenvectors are unlikely to be sparse, that probably cancel the benefit of using a sparse algorithm. The latters are often tailored to compute only a very few eigenvectors but for very very large matrices. So I doubt a sparse algo could be really faster. So if performance in the order of 1s is ok, I'd stick with Eigen's dense module.

sorry, I meant all eigenvalues - the vectors I dont care about right now. So I guess my fastest solution is to go with a snapshot of eigen. Is there some snapshot you can recommend available or should I just try (and pray).

Sebastian

I evaluated FLENS (with Intel MKL BLAS) against Eigen (development snapshot) and my results show a 2-3x speed increase in favor of FLENS/MKL. The test-scenario was to find all eigenvalues of a real symmetric matrix (N=2500). Interestingly, the switch to the intel compiler increased the speed of Eigen a bit, but not the FLENS/MKL combination.



ICC 11.1:
FLENS took 7.80 s

EIGEN took 15.22 s

GCC 4.1.2:
FLENS took 7.79 s

EIGEN took 19.70 s

The code used to solve with Eigen the problem has been:

Eigen::SelfAdjointEigenSolver<matrix_t> solver(E, false);

Eigen::VectorXd evEigen = solver.eigenvalues();

Hope, I got that right, as there was no documentation available.

Regards,

Sebastian

OK for ICC I can't say anything.

There actually is a good simple reason why Eigen is slow at these sizes: the algorithm for that isn't cache friendly at the moment. That will be done for Eigen 3.0.

For GCC: you need to upgrade it first!

It is well-documented (we even say it on the front page of the wiki) that GCC only gives good performance with versions >= 4.2.

GCC 4.4 gives the best performance, GCC 4.2 is a good second choice, GCC 4.3 in third position. GCC 4.1 gives up to 5x slower code than all of them.

Try this:

g++-4.4 -O2 -msse2 -DNDEBUG

Hi!

Gcc 4.4 does not help here. Compiling things on my laptop with gcc 4.4 gives these results:

FLENS took 9.64 s

EIGEN took 22.21 s

Options for gcc:

"g++-4.4" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -msse2 -mfpmath=sse -funroll-loops -fno-strict-aliasing -fopenmp

So, it is not only the compiler, but I think the cache-friendlyness is hurting here a lot. While flens allows for a packed storage and solves everything in place, Eigen does not I think.

Sebastian