Most practical way to speed up calculations?

How much faster is the second scenario compared to the first?:

1. 2015 15" MacBook Pro, 2.2 GHz Quad-Core Intel Core i7, 16 GB 1600 MHz DDR3 running 4 workers in parallel on a optimization problem.
2. 2023 16" MacBook Pro with 12 core CPU, 38 core GPU, 32GB Unified Memory running maximum supported workers in parallel on the same problem.

I am aware that the M2 is running via Rosetta; a beta native version is in release but I don't know if it's reliable.

I'd hate to spend the money on a new laptop then find that it only runs twice as fast or so. I need to see at least a 4x speed increase to justify the expenditure. (fyi, I have optimized everything I can e.g. vectorization etc already).

Thanks

[Walter Roberson]

The GPU is not going to be relevant, except in the sense that the display generation is going to be off-loaded to the GPU by Apple. Not relevant in the sense that MATLAB will not use the GPU (except indirectly by making graphics requests.) gpuarray and other parallel forms are not supported on any current Apple release, and as best I can tell, Mathworks is not working to implement GPU access for the M* series GPU.

[Kevin Johnson]

Thanks Walter.

[Kevin Johnson]

If I really need speed, I guess will have to consider either going to the cloud, or getting a Linux machine?

[Walter Roberson]

Or Windows I suppose...

Answer 1

[Jan]

I've seen many examples in the forum, where the old and fundamental method of vectorization slows down the execution compared to loops. Modern Matlab versions optimze loops very efficiently and the speed of CPU has grown much faster than the speed of RAM access. Therefore vectorized code can suffer from the need of creating large temporary arrays.

It is possible to get a speedup of factor 4 if you upgrade from a 7 year old midclass computer to a highclass current setup. Optimizing code by adjusting it to the properties of modern architecturs can yield much higher speedups - sometimes. We find several examples with a factor of 100 and 10'000 in this forum.

So check the bottlenecks again.

This question contains some Matlab benchmarks on a M2 Mac . This does not look impressive. If speed matters, Matlab on Mac seems to be a bad decision.

[Kevin Johnson]

Interesting, thanks Jan. I will search the forum to see examples of how to adjust the my code to the properties of modern architecturs, since at the moment I don't know what that would mean. But a speed up of that magnitude would solve my problem and then some. Off the top of your head, can you give one such example? Kevin

[Kevin Johnson]

Moving critical code into mex files would be a big help, if I could figure out how to do that.

[Jan]

It would not be efficient, if I start to explain all possible ways to improve code and to post an example for each method. This would fill a book.

Letting me search all corresponding threads in the forum is a bad idea also.

How your code can be implemented in a MEX function would be much easier to explain, if you post the code, which consumes the most time and some matching input arguments.

Let me show just one typical example of sub-optimal code: Matlab's isprime function. Here is a very rough copy of the applied algorithm (error checks and array inputs omitted for clarity):

function isp = isprime(X)

p = primes(sqrt(X));

isp = (X > 0) && all(rem(X, p)); % Vectorized

end

If X is huge, e.g. 9e15 (smaller than flintmax), p has 5'482'508 elements. rem(X, p) determines the remainder of this number of devisions and all searches for a 0 in the output.

This is efficient for prime numbers only. For non-primes too many remainders are computed. Most non-primes can be devided by small primes, such that a loop can stop early:

function isp = isprime_fast(X)

p = primes(sqrt(X));

isp = false;

if X > 1

for k = 1:numel(p) % Loop

if rem(X, p(k)) == 0

return;

end

end

isp = true;

end

end

A speed comparison:

tic;
for k = 1e7:1e7 + 2e5
    q = isprime_lean(k);
end
toc

Elapsed time is 4.945854 seconds.

tic;
for k = 1e7:1e7 + 2e5
    q = isprime_fast(k);
end
toc

Elapsed time is 3.594264 seconds.

function isp = isprime_lean(X)
p   = primes(sqrt(X));
isp = (X > 0) && all(rem(X, p));
end

function isp = isprime_fast(X)
p   = primes(sqrt(X));
isp = false;
if X > 1
   for k = 1:numel(p)
       if rem(X, p(k)) == 0
           return;
       end
   end
   isp = true;
end
end

This is not the a dramatic speed up, but an obvious drawback for vectorized code. Consider that primes(sqrt(X)) alone takes 3.1 sec of the total time already. This means, that the vectorized all(rem(X,p) needs 2.1 sec, while the loop needs 0.5 sec.

[Anton Kogios]

"This question contains some Matlab benchmarks on a M2 Mac . This does not look impressive. If speed matters, Matlab on Mac seems to be a bad decision."

I wouldn't be so quick to dismiss MATLAB on a Mac. Its performace changes for me day-to-day. Over the past week, MATLAB had been running relatively slow for me, but just yesterday/today, it sped up to some of the fastest results I have seen. I am running the R2022b beta for Apple silicon on a M1 Pro MacBook Pro.

Just today, MATLAB opened and was ready in one-two seconds for me (which I have never seen!). I ran bench and got the best results I have seen (I have been using the beta since it was released). See image below.

The fluctuating results are quite intriguing to me. I did not change anything about my setup apart from update my normal R2022b to Update 5, which should not affect the R2022b beta... (I think)