Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Performance degradation of random number generation in MATLAB r2013a

Asked by Alexander on 18 Mar 2013

In MATLAB 2013a, the function random(...) from the Statistics Toolbox runs 40-50 times slower than the same function in the version 2012b.

Ratios of execution times of the following generators:

(a) random('unif', 0,1) and (b) unifrnd(0,1)

are 110 in MATLAB 2013a and 3.1 in MATLAB 2012b.

That is, the function random(...) is 3x slower than unifrnd(...) in MATLAB 2012b, but the same slowdown is 110x in the new MATLAB 2013a.

Any suggestions how to get the new version to perform as quickly as the previous one? (It would be better to have improved performance in the new version, indeed. ;) )

Below is the script used to measure execution times:

N = 5000;
% (a)
tic;
sm = 0;
for i=1:N
    sm = sm + random('unif', 0, 1);
end
toc;
% (b)
tic;
sm = 0;
for i=1:N
    sm = sm + unifrnd(0, 1);
end
toc;

0 Comments

Alexander

2 Answers

Answer by Peter Perkins on 18 Mar 2013

Alexander, I will make a note to look into the difference in performance, but a couple of things you might keep in mind (you may already know these, but just in case):

  • The random function is a switchyard mostly intended to make it easy for a newcomer to find all the possible distributions in one place. If you're writing code that is time critical, you'll want to use the individual random number generator functions like unifrnd.
  • If at all possible, you want to make vectorized calls to random, or even unifrnd, rather than getting one value at a time.
  • random, and to a lesser extent even unifrnd, has error checking and some generality built into them. If performance is really critical, then you might consider using the example from the rand reference page:
       Example 1: Generate values from the uniform distribution on the
       interval [a, b].
          r = a + (b-a).*rand(100,1);

1 Comment

Alexander on 18 Mar 2013

Dear Peter,

thank you very much for valuable advices.

Still, the problem is a slower execution in the new version of Matlab (2013a) of both random('unif', ...) and unifrnd(...) functions compared to the previous version (2012b).

That is, the function random('unif', ...) runs 45 times slower in the version 2013a, while the function unifrnd(...) runs 1.3 times slower in the version 2013a.

Thanks again for your reply

Peter Perkins
Answer by Jan Simon on 19 Mar 2013

More a comment than an answer:

The random streams objects became more and more complicated since Matlab 5.3. When I e.g. want to get a random array controlled by a seed, I have to look in the documentation each time.

Compare:

rand('seed', now)

with:

s = RandStream('mt19937ar', 'Seed', now);
RandStream.setGlobalStream(s);

I understand, that the new random objects are much more powerful. But simple tasks are looking such ugly yet, that I prefer my own random toolbox - although this is known as a bad programming pattern and too many programs suffered from not relying on heavily tested RNGs.

One problem is, that the symbols "rand", "rng", "random" and "RandStream" must be avoided to keep the backward compatibility. Therefore a cleaner and more convenient new tool or a wrapper needs a not matching name already.

Some measurements with the Mersenne Twister (in R2009a and 2011b) look like the standard implementation is used, while there are some SSE-versions available already, which are much faster.

My conclusion: Matlab's RNG tools ran out of control.

5 Comments

Tom Lane on 2 Apr 2013

Yoichi (and others), there were changes in R2013a that make it easier to do certain things, such as add your own probability distributions to the toolbox. That re-architecture is undoubtedly what led to this slowdown.

Peter earlier gave information about this. We regard the random function as a convenience. For best performance it's preferable to produce an entire array of random numbers in a single call, and to call unifrnd or rand directly instead of calling the random convenience function. This would have been true even prior to R2013a.

Nevertheless, if the inability to use random in this way is presenting a problem, it's something we can work to improve in the next release. Let me know.

If you "edit random" you'll see that some distributions are handled specifically in that file, and others are handled by a more generic mechanism. If I needed to use random more efficiently, and I couldn't use any of the techniques above, and I needed this in R2013a, I would add code to the random function so that the uniform distribution is handled specifically in the file. Something like this:

case 'uniform'
    r = unifrnd(varargin{:});
Yoichi Watanabe on 3 Apr 2013

Tom, I would appreciate your thorough explanation on the matter. In fact I used unifrnd instead of random and it runs as fast as the random on 2012b. Perhaps "random" should be removed since it runs so slow or one note should be added in the help for that function. That may be what you write here. Again thank you very much for your quick and adequate reply. Yoichi Watanabe

Alexander on 7 Apr 2013

Tom, the problem is that in the version 2013a both 'random' and 'unifrnd' are slower. The former is approx. 45 times slower (which is a real disaster, IMHO), while the latter one is only factor 1.3 slower.

Both are slower. That is, the new version (2013a) performs worse compared to the previous version.

Jan Simon

Contact us