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

Turn off UMPACK's iterative refinement when called from Arpack #122

Open
WouterJRV opened this issue Feb 23, 2021 · 9 comments
Open

Turn off UMPACK's iterative refinement when called from Arpack #122

WouterJRV opened this issue Feb 23, 2021 · 9 comments

Comments

@WouterJRV
Copy link

Perhaps someone can enlighten us on this ?

https://stackoverflow.com/questions/25065649/arpack-sparse-eigen-solver-many-times-slower-than-equivalent-matlab-eigs

It also aligns with my experience when using Arpack.eigs in Julia vs eigs in matlab

@dkarrasch
Copy link
Member

Somebody said (perhaps in Slack or somewhere in the issues here), that MATLAB dropped its dependency on Arpack and has its own eigs.

@WouterJRV
Copy link
Author

So there is no way to get the same performance to get Julia near the same performance of MATLAB?

This seems to be a bit surprising to me since MATLAB isn't really using a very secret magic algorithm; with the debugging mode one can just enter its code, so I'm trying to understand why Julia (or other languages) aren't able to be on par with its performance. There seems to be a slight difference in default parameters: MATLAB's tolerance seems two orders looser than the one of Arpack, and the starting vector is random instead of zeros. But even changing these parameters in Julia doesn't seem to lead to significant speedup.

@carlomontec
Copy link

carlomontec commented Mar 28, 2021

In my experience with solving generalized eigenvalue problems with positive definite matrices, Arpack.eigs usually is faster than in Matlab, in some cases 2x. In my case I had to set accordingly the explicittransform=:auto parameter which is not yet in the documentation AFAIT. I managed to see it by using the Julia help command

@WouterJRV
Copy link
Author

In my experience with solving generalized eigenvalue problems with positive definite matrices, Arpack.eigs usually is faster than in Matlab, in some cases 2x. In my case I had to set accordingly the explicittransform=:auto parameter which is not yet in the documentation AFAIT. I managed to see it by using the Julia help command

Thanks for your answer. I can't retrieve the precise matrix anymore, but I remember that it was a complex, non-hermitian one (standard, non-generalized EV); and I was looking for the smallest EV's in real or imaginary part rather than the largest.

@ViralBShah
Copy link
Collaborator

I suppose that if matlab is no longer using Arpack, then performance issues may be best filed against other packages that people generally prefer to use nowadays (discussed in various issues in this repo).

@ViralBShah
Copy link
Collaborator

ViralBShah commented Oct 11, 2021

We should probably document the native Julia packages in the README.md here should people coming to Arpack.jl want to try out those packages.

KrylovKit.jl and ArnoldiMethod.jl have been suggested in #87

@simonp0420
Copy link

As reported in this Discourse post, the time for a standard eigenproblem using Arpack.eigs can be reduced to within 1.2x the time required by Matlab's eigs function by setting SuiteSparse.UMFPACK.umf_ctrl[8] = 0

@ViralBShah
Copy link
Collaborator

ViralBShah commented Feb 4, 2023

Turning off UMFPACK's iterative refinement should probably be the default when using Arpack.

@ViralBShah ViralBShah changed the title Arpack seems much slower than MATLAB's eigs? Turn off UMPACK's iterative refinement when called from Arpack Feb 4, 2023
@ViralBShah ViralBShah reopened this Feb 4, 2023
@ViralBShah
Copy link
Collaborator

@rayegun I believe we have turned off UMFPACK's iterative refinement by default for a while now. Can you confirm?

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

No branches or pull requests

5 participants