Textual format is quite limited and storing multidimensional arrays in one txt file is a pain (especially in transferrable way to other software). So this is not really a bug, this is limits of txt.

The quick workaround is to store 2D slices of multidimensional array in different txt files. And then load and assemble slices back into multidimensional array in Mathematica.

For example, you need to store 4 slices of A: A(:,:,1), A(:,:,2), A(:,:,3), A(:,:,4) and then merge them back after reading from files.

Sorry to hear about miscommunication with "big boys". But I am not surprised at all, as my experience with them was the same. I communicated with several top technical people, they tried to extract deep technical information about toolbox internals (and why it is so much faster), but never provided anything in return.  Later on, I saw they tried to implement some  of toolbox's technical "know-hows", but without much success, as I didn't reveal all the details :).

In any case, thank you very much for your time and efforts. Hopefully we can return to this topic later on.

By the way, you need to compute constants (1/3, 2/3) using extended precision: mp('1/3'), mp('2/3').

Otherwise MATLAB evaluates them using double precision. Of course, this must be pre-calculated once before the loop (same as m).

There is still a room for improvement in your code. 

Naturally, extended precision computations are slower compared to double (double run in hardware, extended precision is emulated in software). 

However, how much "slower" depends entirely on the particular code and how it is implemented.

Another important slow-down comes from the MATLAB overhead. Each operation in the M-code results in data copy and passing it to toolbox. This adds non-negligible overhead.

Thus, for higher speed, you might consider re-writing your code to avoid redundant calculations (e.g. b.^2 computed many times) and to use vectorization (when one operation works with vectors & matrices instead of crunching through scalars in the loop). This will reduce MATLAB overhead and allow toolbox to handle data in parallel. You will see nice speed-up.

We will release Linux & Mac OS versions soon.

Great, thank you for the report!

We have just released updated version of toolbox for Windows. It includes bug fix for this issue among other improvements.

Please download it from our homepage (download trial) or just use this link: https://bit.ly/2XwTWH7

Don't forget to copy your license key to the folder of new toolbox version!

Would appreciate if you would test your code with new toolbox and let me know the results. 

Could you please provide minimal, complete, and verifiable example, so that situation can be reproduced?
Please check the top post on the forum homepage: https://mct.userecho.com/

I am not aware of any disadvantages. At least we do not treat AMD any different in our code.

The basic rules is: more CPU cores = higher speed.

If we would compare absolutely equivalent Intel vs. AMD processors (frequencies, number of cores, caches all are the same) - there might be a slight drop in speed if you use Windows.

That is because we use Intel C++ Compiler on Windows, as it produces faster binary code for Intel CPUs.

And, btw, on different platforms performance of all the software packages are different. 

Of course, I would prefer comparison on Windows, as this would be informative for ~80% of users of toolbox.

Why not? I think it is great idea. Also it has sense to extend the tests to cover speed-comparison of FFT and EIG, SVD for special  types of matrices (e.g. banded, Hermitian, complex).

In some if these cases quadruple precision computations in toolbox are faster (at least it was in 2016) than double in MATLAB (in particular solving the banded matrices: https://www.advanpix.com/2016/10/20/architecture-of-eigenproblem-solver/).

The only show stopper for me is (and always has been) significant time and efforts needed to conduct such benchmarks.

I would be happy if somebody would do this (and would help as much as I can). The only suggestion is to use some good many-core CPU, as parallelism is crucially important for matrix computations and FFT.