Why the computing time of a function is bigger than main fuction?

The computational time of first tic-toc is 0.000050 seconds.and second computatioal time is 0.000521 seconds. Nearly ten times bigger. Is there a way to decrease elapsed time for functions?

function main
    clear;
    clc;

      a=1:10000;
      tic
      for i=1:10000
          a(i)=a(i)+1;
      end
      toc

      b=1:10000;
      tic
      b=myfunction(b);
      toc      
  end

function b=myfunction(b)
    for i=1:10000
        b(i)=b(i)+1;
    end
end

Answer 1

[Titus Edelhofer]

Hi Volker,

hmm, it's not a deep copy that happens here. To see, that the operation indeed is done inplace can be seen when using the taskmanager. Run the following code and take a look at memory consumption (note, adapt the size of n to something that does not blow your memory).

function main2
  n = 10000; % this makes a and b a 750 MByte matrix!
  a=rand(n);
  tic
  for i=1:numel(a)
      a(i)=a(i)+1;
  end
  toc
  disp('now b is created <return>')
  pause;
  b=rand(n);
  disp('Now call myfunction <return>')
  pause;
  b=myfunction(b);
end

function b=myfunction(b)
  tic;
  for i=1:numel(b)
      b(i)=b(i)+1;
  end
  toc
end

I see a jump in memory of about 750MB for running until the first pause, and then a jump of the same size when creating b. But no jump when calling myfunction, so b is not copied when going to myfunction.

Why the loop in myfunction is still by a factor of three slower I have no clue and will ask our development.

Titus

Edited: use n instead of hard coded 10000 I had before.

[Jan]

Then this becomes a very interesting question.

[Titus Edelhofer]

That's what I thought as well. As I said, no clue (yet).

[Jan]

Perhaps the JIT cannot register, that the type of "b" is not chaning in the subfunction?

A documentation of the JIT would be extremly helpful!

[Titus Edelhofer]

Hmm, yes and no: since JIT evolves from release to release if one is "too" clever it might not pay off later (for the average user). Of course there are power users who might benefit ...

By the way, the observed behaviour seems to be related to the 64Bit version. On 32Bit the optimizer (JIT) seems to be coping with this situation better ...

[Jan]

Although the JIT can accelerate loops dramatically since Matlab 6.5, I hear the old rumor "FOR loops are brute slow in Matlab" too often. The positive effects of the JIT can be observed, when the debugger is enabled by setting breakpoints, or when the profiler is active: Both would collide with the reordering of the commands, such that the JIT is disabled. Especially for the profiling this is critical, because it reduces the meaning of the results substantially. Suddenly fast loops look like a bottleneck!

I still do not understand, why the dynamic evolving of the JIT is an argument not to publish a documentation. This is funny. Imagine: "Yes, Windows 7 has a lot of new powerful features, but we do not tell you how to use them, because these feature could be change in Windows 8".

I do not think that too many average users will be too clever and create inefficient programs by considering a specific JIT feature only. Only the advanced users will adjust their programs to the JIT, but currently they can't. If a customer asks me, if he can process some data with a program in realtime using WinXY/Linux/MacOS and Matlab20XY.i/abBit, I have no chance but trying it, if the speed depends on the JIT.

I have to write code working with Matlab 6.5 to 2011a. Because a lot of features have changed in this time, I need to branch depending on the Matlab version very often. It would not be a drawback, if I write a general implementation without JIT adjustments, and a specific version adjusted to the JIT of Matlab2009a/32. This will give the full speed on this specific version only - but it does at least. And this can be the dominant argument to use Matlab to solve this specific task.

My opinion: JIT-documentation (even with volatile character) => more power for power-users => more sold Matlab licenses.

Matlab is stable, powerful and user-friendly. The main drawbacks are the slow speed and the weak GUI capabilities. Both of them can be mitigated using undocumented features. So why not document them?!

[Titus Edelhofer]

Hi Jan,

thanks for the detailed discussion. Yes, turning on the profiler already changes the way things are handled. I admit I've been once mislead as well when the profile told me, I was doing a better job then before, but with turned off profiler the contrary was the case. Usually though he fortunately points me to the bottlenecks where to search for inefficiencies.

Regarding the documentation about what JIT does and what not: I don't know about reasons why not to give more detailed explanations about how it works, what it does etc., sorry ...

Titus

Answer 2

[Jan]

The additional time for calling the function is only partially an overhead of the function call. Mainly it is the effect of the required deep data copy of the vector. At first only a reference to the vector b is submitted to the function. But in the first iteration b is duplicated, and this needs time. In opposite to b, the vector a is not duplicated.

You can test the effects by:

function main
a=1:10000;
tic
for i=1:10000
   a(i)=a(i)+1;
end
toc

b=1:10000;
b=myfunction(b);
end

function b=myfunction(b)
tic;  
for i=1:10000
   b(i)=b(i)+1;
end
toc
end

Now I get:

 Elapsed time is 0.000103 seconds.
 Elapsed time is 0.000836 seconds.

To answer your question: No, there is no way to accelerate subfunctions. To gain speed it is useful to avoid deep data copies by processing the variables locally.

[Volkan Kandemir]

Thank you Mr Jan. If the main reason of time differences is calling subfunctions, it is good for us, since it will not increase with the size of the data. However, as you mentioned duplicating big datas is very time consuming.

What you mean by "processing the variables locally." Do you mean don't use subfunctions or there is a way to use subfunctions with out duplicating datas like pointers?

Answer 3

[Titus Edelhofer]

Hi Volker,

which version of MATLAB are you using? For me (R2012a) both your and Jan's version give more or less the same results. With your code the second tic/toc is about 20% slower (only). In "older" versions (if I remember somewhere before R2009a) the function is indeed slower (see Jan's explanation), whereas in newer versions there should be no deep copy involved, the operation on b should happen "inplace" ...

Titus

[Volkan Kandemir]

I am using R2012a too.

How is the second tic/toc slower 20% only? First one is 0.000103 seconds where as second one is 0.000836 seconds on Mr Jans's computer. The ratio is (0.000836-0.000103)/0.000103*100=711% slower!!

Yes I am using inplace functions also global variable but those are not helpfull.

[Titus Edelhofer]

Sorry, I must have made a mistake when running the code (perhaps missed a digit). Now I get the same "bad" ratio as you and Jan ...

Answer 4

[Jan]

function [a, b, c] = main
n = 1e6;
a = 1:n;
tic
for i = 1:n
   a(i) = a(i) + 1;
end
toc

b = subfunc1(n);
c = subfunc2(n);
end

%
function b = subfunc1(n)
b = 1:n;  % Size of [b] depends on input
tic
for i = 1:n
   b(i) = b(i) + 1;
end
toc
end

%
function b = subfunc2(n)
n = 1e6;  % Overwrite input, fixed size of [b]
b = 1:n;
tic
for i = 1:n
   b(i) = b(i) + 1;
end
toc
end

Results:

 Elapsed time is 0.011078 seconds.  main
 Elapsed time is 0.021114 seconds.  subfunc1
 Elapsed time is 0.010048 seconds.  subfunc2

Interpretation: subfunc1 is much slower, because the size of n is not fixed. Obviously the JIT can profit from fixed size loops.