Sorry that this is quite a specific question but I need to diagonalise large matrices for the problem I'm trying to solve and can't for the life of me work out what's going on:

I was expecting that diagonalising these would be much quicker on my desktop than laptop, however there seems to be very little performance difference and in fact my more powerful desktop - every aspect of the system is significantly superior to my laptop - is about 15% slower.

The simplest code that produces the difference is:

AbsoluteTiming[Eigensystem[Table[RandomReal[{0, 1}], {i, 10000}, {j, 10000}],-10, Method -> "Arnoldi"];]

This takes on average about 64 seconds on my desktop but around 58 secs on my laptop. For the specific task I'm trying to solve that difference actually seems larger too.

Any idea what's going on and if there's anyway to solve it? I've read that Mathematica can be a slower on AMD chips than Intel but I seem to get faster performance in almost every task on my desktop than on my laptop... apart from this specific one.

Full specs:

Desktop: AMD Ryzen 5 2600 3.4 GHz 6-core (3.7 GHz Boost), 32 GB 3000 MT/s (2x16 GB) RAM, Intel EVO 970(R 3500, W 2200)

Laptop (Surface Book 1): Intel i5-6300U 2.4 GHz Dual Core (3.0 GHz Boost), 8 GB 1866 MT/s (2x4 GB) RAM, SSD (R 1500, W 600)

Edit: I notice that the CPU usage in Task Manager is slightly different - running at around 60-65% for the laptop but at 50% for the desktop. Is there perhaps a different implementation of Arnoldi for Intel that can take advantage of multiple cores? Laptop CPU usage Desktop CPU usage Edit 2 Logical processors view of task manager for desktop enter image description here

  • $\begingroup$ I am just curious: Does this happen also for positive-definite input matrices? $\endgroup$ Jan 28, 2019 at 19:16
  • $\begingroup$ Nope the specifics of the matrix seems to make little difference to the difference in timings between the computers. $\endgroup$ Jan 28, 2019 at 19:27
  • $\begingroup$ Hm. Okay. I've just read this morning that ARPACK++ implements its own data type for machine precision complex numbers; compared to FORTRAN's native complex data type, this data type is said to severe performance issues... $\endgroup$ Jan 28, 2019 at 20:58
  • 2
    $\begingroup$ I've added that to the post. Looks like all 6 are being used at ~100% $\endgroup$ Jan 29, 2019 at 6:41
  • 2
    $\begingroup$ It might be interesting to run Needs["Benchmarking`"]; BenchmarkReport[] on both configurations. The results of tests 9 and (maybe 8 and 10) should be of particular interest. If the result of test 9 is similar to your tests with Eigensystem, this might be an indication for both suboptimal BLAS and fewer FMA units on the Ryzen. Btw., it would also be interesting to see whether Module[{m1, m2}, AbsoluteTiming[SeedRandom[1]; m1 = RandomComplex[{}, {1050, 1050}]; m2 = RandomComplex[{}, {1050, 1050}]; Do[m1.m2, {12}]]] (test 9 for complex numbers) leads to unexpected timings. $\endgroup$ Jan 29, 2019 at 12:44

1 Answer 1


Here are some possible explanations that came to my mind. But after further thinking, not all of those should really apply to OP's situation. However, I leave them for documentation reasons.

  • Probably Mathematica uses a non-parallelized implementation of Anoldi's method. In single-core performance, these processors are not that much different: https://cpu.userbenchmark.com/Compare/Intel-Core-i5-6300U-vs-AMD-Ryzen-5-2600/m27864vs3955. But thinking of it: By Haswell Quad Core executes this Eigensystem at 400 % CPU speed (that's macOS' way of telling me that it runs on all cores without hyperthreading) and it only takes about 29 seconds...

  • Arnoldi's method uses mostly matrix-vector multiplications. Those are usually far from operating at peak floating point performance in case of sparse arrays because they are somewhat memory bound (nearly random access of memory is required). For dense matrices however, these are usually highly optimized. So this is probably also not the reason for the Ryzen not profiting from its peak performance... -- unless the BLAS that Mathematica uses on your system is really shabby. Which leads to the next point:

  • Mathematica uses the Intel MKL for many numerical tasks and these libraries are best optimized for - guess what - Intel CPUs. Thinking of it, this is probably not the case for Arnoldi's method; I heard once that Mathematica uses ARPACK... But again, ARPACK needs some BLAS implementation for matrix-vector multiplication and it is quite reasonable to expect that the ARPACK library distributed with Mathematica is linked against BLAS from Intel MKL (which is also shipped with Mathematica). And the latter is probably suboptimal for CPUs from other manufacturers...

  • $\begingroup$ Thanks for the response. It does seem it might be related to the Arnoldi algorithm. On both machines not specifying the algorithm slows the computation down overall but gives about 68 seconds for the Ryzen and 72 secs for the Intel (although does it just decide to chose Arnoldi anyway?) What speed is your Haswell? $\endgroup$ Jan 28, 2019 at 19:06
  • $\begingroup$ This is my CPU. $\endgroup$ Jan 28, 2019 at 19:09
  • 2
    $\begingroup$ @RamProblems: Intel Haswell and Skylake (i.e. your i3-6300U) have twice the raw FMA throughput per core per clock vs. Ryzen. (2x 256-bit vector FMA units, vs. 2x 128-bit in Ryzen). If this workload is bottlenecking on ALU throughput like a dense matmul with efficient cache-blocking would, then that explains a good fraction of the difference. See Why is an AMD Ryzen 2700x 2x slower than a 3-year-old laptop Intel i7-6820HQ with Python? (SKL quad-core vs. Zen 8-core) where FMA throughput explains ~half of the difference. $\endgroup$ Jan 29, 2019 at 0:38
  • 2
    $\begingroup$ There are also differences in memory / cache, but those don't obviously favour the dual-core Skylake CPU. Ryzen uses clusters of 4 cores sharing an L3 cache (with higher inter-core latency across clusters than within one cluster), so maybe inter-core data movement is a problem too, using all 6 cores. SKL does have excellent L1d and L2 cache bandwidth, though, and pretty good bandwidth to its shared L3. It's still a surprising result, and yeah might be due to software that's much better tuned for Intel, possibly with some cripple-AMD thrown in for good measure in Intel's libraries. $\endgroup$ Jan 29, 2019 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.