Backslash (\) operator became much slower when updating from 2015b to 2019a
7 次查看(过去 30 天)
显示 更早的评论
Hello,
we recently updated our pretty old Matlab version from 2015b to 2019a, also due to hope for increased code performance.
A big simulation code of mine, which solves a lot of nonlinear (and hence also linear) systems, is now much slower than in the old 2019b version. Using the profiler, I was able to quickly find the root cause of the issue: The backslash operator, at least in my case, became slower by a factor of approximately 2.
My code is simply:
dx = -jac\f;
In my case, the matrix (called jac) is a 1438x1438 sparse matrix, the spy plot looks as follows:
![spy.PNG](https://www.mathworks.com/matlabcentral/answers/uploaded_files/230442/spy.png)
The vector f is a non-sparse 1438x1 vector.
Doing (repeated and averaged) timing tests with the following code:
timeit(@() -jac\f)
yields
0.0054 on Matlab 2015b, and
0.012 on Matlab 2019a.
What is going on here? Has the algorithm selection in mldivide/backslash operator changed in the recent years? How can I get back to the old performance?
Trying to reproduce the problem in a more general and simple setting, I composed the following code:
Adense = diag(ones(4e3,1));
Asparse = sparse(Adense);
b = rand(4e3,1);
Duration_dense = timeit(@() -Adense\b)
Duration_sparse = timeit(@() -Asparse\b)
On my machine, this yields for Matlab 2019b:
Duration_dense =
0.0823
Duration_sparse =
3.6871e-05
In Matlab 2015b, I get the following for the same code as above:
Duration_dense =
0.0813
Duration_sparse =
3.8327e-05
I think this proves that in both the old and new versions, sparse matrices are correctly recognized as such (anything else would have been shocking). The issue might then be related to the specific sparsity pattern of my matrix.
Does anyone have an idea what is going on here?
Thank you!
0 个评论
采纳的回答
Christine Tobler
2019-7-19
Thank you for these logs. The difference in behavior comes from the following message, saying that we repeat the factorization with different options:
sp\: However, UMFPACK may have failed to produce a correct factorization
possibly due to aggressive pivot tolerances or because the problem
is ill-conditioned.
sp\: These tolerances were:
Pivot Tolerance: 0.1
Diagonal Pivot Tolerance: 0.001
We will factor the matrix again but use standard partial pivoting.
This is done because we heuristically determined that it's likely for the result of the first computation not to be accurate enough. This tolerance was tightened recently, which would be why it's now showing up for this matrix.
There are parameters in spparms that can affect the behavior of the sparse LU solve ('piv_tol' and 'sym_tol') which may be changed to avoid this behavior. You could use spparms to check if this works.
Note these options will also affect the accuracy of the result, so it's a good idea to check the residual while you are modifying the parameters, and to, if possible, only use modified spparms settings in the context where you need them. These are global variables that will affect the behavior of every call to backslash in a MATLAB session.
0 个评论
更多回答(2 个)
Christine Tobler
2019-7-19
Based on the spy plot, I would be astonished if a different method was selected between the two releases - I think the LU solver is the only viable candidate for this matrix.
However, there are several options to the LU solver that are chosen heuristically, and we have adusted some of them. The best way to see what is going on would be to use the command
>> spparms('spumoni', 2)
and then call backslash. This will show diagnostic messages about what methods and options are selected in each version. Could you run this in both releases and post the diagnostic messages here, please?
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Function Creation 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!