mldivide take too much time
Show older comments
Hi guys,
I am solving compressible NS using FEM , and I wrote my solver using MATLAB.
currently I have a problem with the running time ( 90x30 grid ). One time step takes about 22 seconds, 20 seconds of them are in the inverse line ! I dont know why it takes this much time !.
19 Comments
Ameer Hamza
on 14 Mar 2020
mldivide is probably the fastest you can get to solve such equations in MATLAB. Maybe try to review your algorithm and see if there is a way to reduce the dimensions of the matrices involved in this step.
John D'Errico
on 14 Mar 2020
Computers are not infinitely fast. People seem to think they are, but not so. Perhaps you watch too much TV, where the computers are always able to do amazing things in a fraction of a pico-second, when the user only had to click a couple of keys on the keyboard.
Since we cannot see into your computer, we cannot offer any useful advice. If you are unhappy with the speed of your code, then you could also get a faster computer, or change the overall algorithm (mldivide is, as has been said, already about as fast as it can be) or use less data (expect even worse results, since using less data is never a good idea.)
Changing the overall algorithm may mean to completely change what you are doing. That is, if mldivide is taking too much time for you, then restructure things so it needs to call mldivide less often.
Or, the answer may simply be to sit down with a good book and a cup of coffee, while the existing code finishes its work. What good book could I suggest, one that would be most appropriate here? Any good text on numerical methods in computing would be a good start, since it would help you to understand the algorithms involved.
dpb
on 14 Mar 2020
And it took all of some 20 sec...hardly a crisis it would seem unless this is something that has to be done thousands of times.
David Goodmanson
on 14 Mar 2020
Hi yusuf, what is the size of globalmat, and is is real double precision numbers?
Walter Roberson
on 14 Mar 2020
If this is inside a loop, do not xlsread() within the loop if you can avoid it. If you are reading the same thing each time, read it once outside the loop and then pass it down to each routine that needs it.
dpb
on 14 Mar 2020
" do not xlsread() within the loop..."
Good advice and with 12 calls it's likely at least some of those might be avoided but...altogether they're 8% of the total while 90% is in builtins, overhead, etc, ... Dunno if there's some way to get a feel for what those might be, more specifically, Walter?
W/ no code to look at, wonder if there's some issue like not preallocationg or the like going on.
@Yusuf--have you looked at all the lint suggestion in the code editor for things it can suggest and eliminated all those? If not, there's good chance there are some worthwhile suggestions there.
yusuf albadry
on 14 Mar 2020
Walter Roberson
on 14 Mar 2020
Could you confirm that globamat is 11284 by 11284, and that globalrhs is 11284 by 1 ?
If you experiment with
globalmat = rand(11284);
globalrhs = rand(11284,1);
tic; globalmat\globalrhs; toc
then what kind of timings do you get? I get around 8 seconds on my (2013) system.
Will globalmat have any special properties such as being a band matrix? In some cases there are faster algorithms. mldivide can figure out some of the patterns, but not always, and it takes time to probe the patterns that could be avoided if you know ahead of time that the pattern is there.
dpb
on 14 Mar 2020
" am doing the inverse operation for at least 100 times,"
The biggest change likely would be to find a way to recast the implementation to avoid the explicit inverse.
You're not going to speed up builtin \ operator as it's already code.
yusuf albadry
on 14 Mar 2020
Walter Roberson
on 14 Mar 2020
My system is not especially fast: it is a 3.5 GHz i7 system. Your system appears to take pretty close to twice the time for the \ operator, suggesting that you might be running at roughly 1.8 GHz.. though I guess in theory you might be up around 2.0 GHz if you have an i3 processor.
This might be time to obtain access to a faster system, perhaps use a cloud computing facility.
Walter Roberson
on 14 Mar 2020
You did not answer my questions about the size of the matrix, and about whether it has any special patterns ?
yusuf albadry
on 14 Mar 2020
yusuf albadry
on 14 Mar 2020
Walter Roberson
on 15 Mar 2020
Did you happen to follow the guidelines to speed up ryzen ?
yusuf albadry
on 15 Mar 2020
Walter Roberson
on 15 Mar 2020
Apparently it can make a big difference.
Walter Roberson
on 15 Mar 2020
If your matrix is real-valued then if it is symmetric then it is also Hermitian -- equal to its complex transpose.
In such a case if the diagonal is all positive or all negative, then you might be able to use cholesky; if the diagonal does not meet that condition then LDL is used.
yusuf albadry
on 15 Mar 2020
Answers (2)
Walter Roberson
on 18 Mar 2020
1 vote
To summarize: the most important issue was that the poster had a Ryzen, which is at a disadvantage when using the Intel high performance Math library MKL. Fortunately a user has posted information on how to speed it up; https://www.mathworks.com/matlabcentral/answers/396296-what-if-anything-can-be-done-to-optimize-performance-for-modern-amd-cpu-s#answer_401963 and when the poster did that, they doubled performance.
Precise Simulation
on 5 May 2020
0 votes
You can also try the MUMPS linear solver which is also is up to 30-50% faster than mldivide (Umfpack) in serial mode (and also supports parallel), and is available as pre-compiled Matlab Mex files with the FEATool Multiphysics toolbox
Categories
Find more on Performance and Memory in Help Center and File Exchange
on 14 Mar 2020
on 5 May 2020
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
