On 1/7/2013 11:29 AM, Sida wrote:
> Hi
> I really want to revisit the problem of slow for loops in matlab, to
> understand what's going on beneath the hood. And also about the
> mysterious matlab JIT.
> % My example for today:
> sum = 0;
> thing = 1;
> for t=1:1e7
> sum = sum + thing;
> end
>
> And this runs very slow in matlab (13.26 sec), compared with a simple
> C++ loop (0.06 sec). I want to understand where does the overhead come
> from, and if it can be eliminated.
> C++ will do this calculation on the stack, and i assume matlab does this
> somewhat differently(?)
...
Just for grins since sum is a builtin procedure and you're overloading
it, you might try your same test w/ a different variable for the
accumulator. I don't know if it'll make any difference at all but it is
in general a bad idea to overload Matlab function names, particularly
ones so common. I know it's just a test case and not "real" code but
good habits are best to develop early and keep to...
OK, since I've now got a newer version I decided to test the theory
(especially since the run time you showed seemed exceedingly excessive
for the simple loop even granted that ML is interpreted instead of fully
compiled).
So,
>> thing = 1;
>> s=0;tic;for i=1:10E5,s=s+thing;end;toc
Elapsed time is 0.009741 seconds.
>> s=0;tic;for i=1:10E5,s=s+thing;end;toc
Elapsed time is 0.009738 seconds.
>> s=0;tic;for i=1:10E6,s=s+thing;end;toc
Elapsed time is 0.098500 seconds.
OK, using a variable is more like one would expect and shows good
reproducibility and scaling as expected...
>> sum=0;tic;for i=1:10E5,sum=sum+thing;end;toc
Elapsed time is 1.554245 seconds.
>> sum=0;tic;for i=1:10E6,sum=sum+thing;end;toc
Elapsed time is 15.391827 seconds.
>>
All right, so now we overload sum() -- and voila!!!! we have found the
culprit it appears.
"Doctor, it hurts when I do that."
"Then don't do that."
There's a moral in there somewhere methinks...
--
> Hi
> I really want to revisit the problem of slow for loops in matlab, to
> understand what's going on beneath the hood. And also about the
> mysterious matlab JIT.
> % My example for today:
> sum = 0;
> thing = 1;
> for t=1:1e7
> sum = sum + thing;
> end
>
> And this runs very slow in matlab (13.26 sec), compared with a simple
> C++ loop (0.06 sec). I want to understand where does the overhead come
> from, and if it can be eliminated.
> C++ will do this calculation on the stack, and i assume matlab does this
> somewhat differently(?)
...
Just for grins since sum is a builtin procedure and you're overloading
it, you might try your same test w/ a different variable for the
accumulator. I don't know if it'll make any difference at all but it is
in general a bad idea to overload Matlab function names, particularly
ones so common. I know it's just a test case and not "real" code but
good habits are best to develop early and keep to...
OK, since I've now got a newer version I decided to test the theory
(especially since the run time you showed seemed exceedingly excessive
for the simple loop even granted that ML is interpreted instead of fully
compiled).
So,
>> thing = 1;
>> s=0;tic;for i=1:10E5,s=s+thing;end;toc
Elapsed time is 0.009741 seconds.
>> s=0;tic;for i=1:10E5,s=s+thing;end;toc
Elapsed time is 0.009738 seconds.
>> s=0;tic;for i=1:10E6,s=s+thing;end;toc
Elapsed time is 0.098500 seconds.
OK, using a variable is more like one would expect and shows good
reproducibility and scaling as expected...
>> sum=0;tic;for i=1:10E5,sum=sum+thing;end;toc
Elapsed time is 1.554245 seconds.
>> sum=0;tic;for i=1:10E6,sum=sum+thing;end;toc
Elapsed time is 15.391827 seconds.
>>
All right, so now we overload sum() -- and voila!!!! we have found the
culprit it appears.
"Doctor, it hurts when I do that."
"Then don't do that."
There's a moral in there somewhere methinks...
--