MATLAB Answers

small matrix multiplication *much slower* in R2016b than R2016a

4 views (last 30 days)
Adrian
Adrian on 15 Nov 2016
Edited: Jan on 28 Jan 2017
Hi all,
I find that multiplication of small matrices seems much smaller in R2016b than R2016a. Here's a minimal example:
r = rand(50,100);
s = rand(100,100);
tic; r * s; toc
This takes about 0.0012s in R2016a and 0.018s R2016b.
Creating an artificial loop to make sure this isn't just some initial overhead or something leads to the same loss factor:
tic; for i = 1:1000, a = r*s; end, toc
This takes about 0.18s in R2016a and 2.1s R2016b.
Once I make the matrices much bigger, say r = rand(500,1000); and s = rand(1000,1000), the version behave similarly (R2016b even seems to be ~15% faster). Anyone have any insight as to why this is, or can verify this behavior on another system?
I wonder if it has to do with the new arithmetic expansions implementation (if this feature has some cost for small matrix multiplication): http://blogs.mathworks.com/loren/2016/10/24/matlab-arithmetic-expands-in-r2016b/
Thank you
- Adrian
  8 Comments
Adrian
Adrian on 16 Nov 2016
This is my intuition as well. Unfortunately, each of my small sparse matrices are slightly different sizes.
Of course, I can figure out how to keep them in one long vector by keeping indices around, and that's what I'm doing, but this is rather cumbersome and has its own slow-downs.

Sign in to comment.

Answers (1)

Jan
Jan on 16 Nov 2016
Edited: Jan on 28 Jan 2017
When you run the code in the command window, Matlab's JIT acceleration cannot or does not optimize the execution time, or perhaps only partially. The JIT is subject to changes between versions, so I stopped to check this. The JIT identifies variables processed in loops and if they do not change their type, they are addressed faster - at least it looks like, because the JIT is not fully documented. When you have many variables in the workspace and Matlab has to access one, it must search in the lookup table for symbols, to find out, if a symbol is a variable, function, java class, etc. This lookup is time-consuming and a huge workspace can slow this down.
An evil example code:
tic
r = 1;
a = 0;
for i = 1:1000
a = a + r * rand;
if rand < 0.0001
r = @myFunctionWhichReplies_31415
end
end
toc
Now Matlab has to lookup the symbol "r" in each iteration. Even if this code is included in a function, the JIT cannot avoid this. But without this evil change, the loop is accelerated by recognizing that "r" is always the same array.
As soon as an eval or assignin('caller') modifies the lookup table for symbols, the JIT cannot optimize the code anymore and the speed of loops can degrade substantially. Changing the type of a variable anywhere in the code can impede the acceleration also.
So, this answer does not match the question, but it explains, why running code in the command window with a large base workspace can slowdown the execution such that the observed differences can happen.
[EDITED] As Philip Borghesani has mentioned in the comments: The JIT is developping and not documented. Some of the statements of this answer might concern certain Matlab releases only. It is questionable, if code should be optimized for a specific JIT version, but it is a good practice to try at least not to impede this tool.
  4 Comments
Philip Borghesani
Philip Borghesani on 16 Nov 2016
Jan, older (pre R2015b) information on the jit most likely does not apply to recent MATLAB versions based on the new execution engine. It is much less sensitive to things like variables that change type and does not fall off a cliff like the previous jit tended to.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!