Matlab JIT engine nested loops data type

In the textbook "Matlab programming for engineers" by S.Chapman (4th edition) it is stated that (see pp. 165-166)

1. The JIT compiler only accelerates loops containing double, logical, and char data types (plus integer data types that we haven’t met yet). If other data types such as cell arrays or structures appear in the loop, it will not be accelerated.
2. If an array in the loop has more than two dimensions, the loop will not be accelerated.

I would like to know if the information provided above is still accurate (I am using the newest Matlab release, R2021a).

[Stephen23]

You did not write the date of publication, but according to this link

https://www.mathworks.com/academia/books/matlab-programming-for-engineers-chapman.html

the sixth edition was updated for R2018a. I suspect that this means the fourth edition does not even include the totally new Execution Engine that was introduced with R2015b (and will differ even more from your R2021a):

https://blogs.mathworks.com/loren/2016/02/12/run-code-faster-with-the-new-matlab-execution-engine/

https://www.mathworks.com/company/newsroom/mathworks-announces-release-2015b-of-the-matlab-and-simulink-product-families.html

Unless the author has a very honored relationship with TMW it is unlikely that they have any such knowledge about unpublished JIT/Execution Engine behavior of the kind that you asked about. You should simply assume that any printed MATLAB guide is outdated the day after it is published.

[DGM]

FWIW, 4th ed was circa late 2007, so that's pretty old.

Answer 1

[Jan]

This is a good question. Matlab's JIT was partially documented in Matlab 6.5 (2001), but afterwards MathWorks avoided to publish details. They have the good reason, that publishing details of the JIT would motivate users to adjust their programs to the JIT, but they want to adjust the JIT to the programs.

Some tests might show, that the mentioned limitations are not matching anymore.

function s = stupidTest(x)
s = 0;
for k = 1:numel(x)
    s = s + x(k);
end
end

Calling this with 2D arrays has the same speed as with 3D arrays, if the number of elements is equal.

Impeding the JIT on purpose slows the code down, e.g. by s = eval('0');

Yes, the test case is very basic. But I'd avoid to adjust the code too much to assumed properties of the JIT.

[Alessandro D]

Thanks for your answer, Jan! Based on your test code, I was also interested to understand if Matlab works faster with one loop and linear indeces (what you do in the function stupidTest) or with subscripts and nested loops.

So here is my test code:

% Let's consider a 3-dim array
% We want to compute the sum of all its elements using loops instead of the
% obvious sum(A,'all')

A = rand(800,800,800);

disp('Using command sum:')
tic
total0 = sum(A,'all');
toc

disp('Using linear index, i.e. only one loop:')
tic
total1 = stupidTest(A);
toc

disp('Using subscripts, i.e. 3 nested loops:')
tic
total2 = stupidTest_nested(A);
toc

% Check that total1 and total2 are the same
isequal(total1,total2)

And the functions called by the script above are as follows:

function s = stupidTest(x)

n = numel(x);

s = 0;
for k = 1:n
    s = s + x(k);
end

end

and

function s = stupidTest_nested(x)
% Assumption: x is a 3-dim array

n1 = size(x,1);
n2 = size(x,2);
n3 = size(x,3);

s = 0;

for i3 = 1:n3
    for i2 = 1:n2
        for i1 = 1:n1
            s = s + x(i1,i2,i3);
        end
    end
end

end

Of course using "sum" is the fasted approach, but with my surprise Matlab is faster with the 3 nested loops than with the "linear index and one loop" combination:

Using command sum:

Elapsed time is 0.120381 seconds.

Using linear index, i.e. only one loop:

Elapsed time is 0.599606 seconds.

Using subscripts, i.e. 3 nested loops:

Elapsed time is 0.488547 seconds.

[Jan]

@Alessandro D: This is an interesting result. It might be different in other Matlab versions due to modifications of the JIT. Which Matlab version did you use?

[Alessandro D]

@Jan I used R2021a

[DGM]

I figured I'd give it a whirl, since I'm perpetually out-of-date and able to share the perspective that comes with running older versions.

Out of the gate, I don't have enough memory to wrangle that large of a DPFP array without being pushed into swap:

800x800x800 R2019b

Using command sum:

Elapsed time is 47.013714 seconds.

Using linear index, i.e. only one loop:

Elapsed time is 177.289160 seconds.

Using subscripts, i.e. 3 nested loops:

Elapsed time is 197.953229 seconds.

I know well enough that switching to single precision often slows things down, memory usage aside. I decided to try with a smaller array to keep away from swap usage, but my experience is still the opposite of yours for R2019b and R2015b:

600x R2019b

Using command sum:

Elapsed time is 0.133028 seconds.

Using linear index, i.e. only one loop:

Elapsed time is 2.440955 seconds.

Using subscripts, i.e. 3 nested loops:

Elapsed time is 2.539198 seconds.

600x R2015b (using sum(A(:)) )

Using command sum:

Elapsed time is 0.136865 seconds.

Using linear index, i.e. only one loop:

Elapsed time is 4.313646 seconds.

Using subscripts, i.e. 3 nested loops:

Elapsed time is 7.171336 seconds.

But look at good old R2009b doing its own thing:

600x R2009b (using sum(A(:)) )

Using command sum:

Elapsed time is 0.204012 seconds.

Using linear index, i.e. only one loop:

Elapsed time is 4.270620 seconds.

Using subscripts, i.e. 3 nested loops:

Elapsed time is 2.084054 seconds.

I don't know if I'd contribute this all to version differences. Hardware and environment matter too.