Matlab 2018a with parallel computing too slow

I run a script which is basically a for-cycle that executes non-linear fitting with a custom function (gaussian and erf's) on 10-20 samples at every iteration. The [x y] data at each iteration is taken from a (x,y,n) array already in the workspace, with n very large (i.e. 65000). I used for years Matlab R14 (2004), now running on my laptop (CPU intel i5-2540M 2 cores) with W7 but wish to use parallel computing (I did not have the toolbox on R14) so I installed Matlab 2018a. These are the execution times (tic-toc):

1) for-cycle for reading the data file and generating the 3D array (x,y,n=1000): 20s (R14, no PC) and 7s (2018a both for 1 and 2 cores).

2) for cycle to do n=1000 non-linear fits: 128s (with R14, no PC), 229s (with 2018a, no PC), 146s (with 2018a, PC 2 cores),

It looked very disappointing, the R14 proved to be the fastest, without PC. Moreover I installed Matlab 2018a on a powerful server 2x Xeon X5660 (in total 12 cores) with 48 GB RAM. The execution time for the same script and data (n=1000 fits), is about 41s, more or less a factor 3 better the R14 without PC.

Does anyone know the reason for such moderate or no improvement at all and any remedy?

Thank you in advance.

[Philip Hoang]

I think I am encountering a similar problem to you. I am running a (x,y,n) n-array (n=400,x=4000) and sampling [x y] for a optimization. Testing 2014b and 2018a I have found for the exact same code, that there is some very strange behavior: much more cores are currently being used, and there is more memory usage, whereas previously only a few cores were being used (but still efficiently), yet the code does not execute faster. I run 2 x 12core xeons (total 24-cores) and one 2018 instance can now occupy 50% of cores continuously and run huge CPU hours, whereas testing under 2014b I can run many instances no problems and limited only by ram. I am investigating the cause, but I suspect that there has been some new implementation of for-loops which attempts to speed up (or parallelize?) the loops, which seems successful for small loops with limited data, but when applied to larger data-sets, creates inefficiencies in the computation with absolutely no core-scaling advantage in my case.

[Andrea Castoldi]

Thanks for the further info, let me know if you understand more. My worry is that when I won't be able any more to install/maintain old&fast Matlab versions on new Win10 computers, then I will have to turn to a compiled language for certain tasks (but loosing the ease of visualization and high level functions).

Answer 1

[John D'Errico]

Parallel computing need not always gain. Why not? Because MATLAB already automatically does some multi-threading when it thinks it can see some gain, on SOME operations.

So, suppose you wanted to perform some operations, ones that happens to be included among the set of operations that are already multi-threaded? You will take away the ability to multithread that computation, because now you are using those processors yourself. The same number of adds and multiplies may be performed, but in a different order. But since the BLAS are VERY efficient in what they do when they are able to act as designed, you may actually lose out in overall throughput.

So I'd not be amazed if you saw no gains, as MATLAB may already have been making good use of the capability available to it.

There may be other issues, because the behavior of two systems will not be identical, two MATLAB releases, etc. In some cases, network issues may actually be a significant factor, so comparing two systems may not always be trivial.

Answer 2

[Andrea Castoldi]

Thanks for the answer. I agree on the non-obvious speed factor achievable with PC. Still it puzzled me that such a powerful server gained so little (though it gained 3x at the end). However it apparent that the 2004 release (no PC) is much faster than the 2018 release on 1 core (again no PC). And this is beyond the general argument you said, no PC is involved here.

[John D'Errico]

Please use comments when you want to make a comment.

Bech might tell you something about speed of the two systems, but be careful, as bench itself changes over the years. So they change problem sizes, etc. I wish there was a flag in bench, that would allow you to tell it to use the version of bench for R1014.

Use a system monitor to watch to see how many processors are running on your problem, even when no parallel computing TB is involved.

[Andrea Castoldi]

The results for Bench are:

LU /FFT /ODE /Spar/2D /3D

0.19/0.10/0.12/0.20/0.22/0.12 (Matlab R14)

0.30/0.20/0.03/0.14/0.64/1.32 (Matlab 2018a)

I checked that 1 core was used. This seems confirming that R14 is still better for most tasks, except ODE.