Eigendecomposition not fully utilizing all cores on M1 pro, matlab 2025b

Is there any way to speed up the computation of a spectral decomposition on a apple silicon mac m1 pro in matlab 2025b when the matrix is large? The following observation were made on Mac OS Sequoia I notice that not all my cores are fully utilized in the activity monitor. The Cholesky decomposition is more than 10x faster and utilizes all cores in the activity manges

Evaluating the following code takes about 10s with n=40,h =60, and about 6s with n=30,h=60.

Edited: Update to Mac Os Tahoe improved performance and performance core were fully utilized in activity manager.

n= 40;
h = 60;
Adraw = randn(n*h,n*h);
Sigma = Adraw*Adraw';
tic
for iter = 1 : 10
    [V,D] = eig(Sigma);
end
toc

Answer 1

[John D'Errico]

Some operations are not as easily parallelized when utilizing automatic mutithreading. That is possibly the case for eig, where a 2Kx2K matrix may not be ufficiently large to benefit. A Cholesky factorization is pretty simple in comparison. Mostly a lot of very simple linear algebra there.

However, I just tested your code snippet out, and it runs way too fast to get an accurate view of what is happening, at least unless you are careful.

Under activity monitor/view/update frequency, set it to look as frequently as possible. In my OS release (Tahoe), it can sample as quickly as once per second. Do that. (When I tried your code with a slower sampling frequency, it never saw that all cores were being utilized. But that was just because the activity monitor blinked and it was all done. The default sampling frequency on my machine was every 5 seconds, and that was far too slow. If the sampling rate is too slow, thus significantly longer than the event it needs to see, then you cannot accurately measure what is happening. Think in terms of Nyquist frequency.)

So next, I expanded your loop out to 200 passes, to insure that activity monitor will see everything it needs to see.

n= 40;
h = 60;
Adraw = randn(n*h,n*h);
Sigma = Adraw*Adraw';
tic
for iter = 1 : 200
    [V,D] = eig(Sigma);
end

Then I carefully monitored the activity monitor on my M4 CPU, which has 12 performance cores, and 4 efficiency cores. The latter group of cores are often not used for multi-threaded computations. (There are some computations I can do which will utilize all 16 of my cores, but not all. A parfor loop, for example, will use them all if I wish. At this moment as I write this, 15 of my cores are very busy.) So indeed, MATLAB was using all 12 performance cores, running them all flat out.

And this tells me there is absolutely nothing more to be done in this case, at least on my M4 CPU, running 2025b. My guess is, that may also be the case for your M1 machine, if you run the test for more than a few seconds, and you force the activity monitor to sample as quickly as possible. That 2Kx2K eig call really is grabbing all the cores it can find.

[Benny]

Revised:

Thank you very much for investigating the issue. In the mean time i updated to tahoe from sequoia, which seems to improve performance in Matlab 2025b and also leads to full utilization of the performance core with the longer loop.

I observe now that the eigendecomposition takes about a total of 131 seconds for 200 iterations on my M1 pro macbook, so roughly 0,65 eigendecompositions per second. Compared to a windows machine with an intel xeon Gold 6342 CPU with 2,8 ghz and 16gb of ram the computation timel is somewhat faster with 105 seconds, 0,55 per draw.

For the same loop, Cholesky takes about 3.3 seconds on the mac and windows machine.

So there seems to be some inefficiencies left to the eigendecompositions on the mac, at least with respect to M1 pro.

[John D'Errico]

As I said, cholesky is almost trivial compared to eigenvalues. The basic algorithm can be written in only a few lines of code.

That different architectures take different amounts of time on different problems is expected. This is why the bench code was written to explore a variety of different problems. Different machines have different amounts of RAM, cache sizes, buses, etc. They are designed with different targets in mind.

As far as EIG being inefficient on one class of machine, that goes back to tools like LAPACK, some variant of which is probably used to perform the EIG call. Remember that EIG is not written in MATLAB itself. Instead, MATLAB acts as a wrapper for many of these calls. One thing MathWorks will never wish to do is to write and maintain basic codes like an eigenvalue or SVD, when high quality existing codes for those operations exist in a library like LAPACK. In fact, one problem that MATLAB had was for several years, native libraries for the M-series processors did not exist. So the slow time for EIG may be just an artifact of that.

I would assume that at some point, the library codes for the Apple M-series processors will get updates. When that happens in some future release, EIG might get a speed boost on the Mac. It may never happen of course, if Apple decides to move towards other processors. I'd want to point out the use of the A18 chips in some new Macs we see now. These codes often need to chase a moving target.

[Walter Roberson]

Note by the way, that the M1 through M4 GPU have no built-in FP64 or I64 operations -- so there cannot be any GPU acceleration of the calculations (not unless FP64 operations are emulated in software, which is typically a calculation that runs at 1:32 of the FP32 GPU speed.)

Answer 2

[Matt J]

Perhaps bundle the jobs together using pageeig?

[Benny]

No this wouldn't work in my application because I do baysesian forecasting which requires non-iid Gibbs sampler. Therefore, I have to do it in a loop to compute the eigendecomposition. In my application, my covariance matrix may be singular because of the restrictions imposed. Therefore, I need to do the eigendecomposition in these cases.