MATLAB: Profiler Paradox

for loopoptimizationparadoxparallel computingprofiler

In an attempt to rotate multiple 3×3 matrices I use two approaches. The first is by running a for loop in which I rotate each job separately. The other approach is where setup a sparse block diagonal matrix and rotate once. In order to find out which is most time-efficient I place tic-toc's around each function and I also use Profiler.

Like this:

tic
function1
toc
tic 
function2
toc

The paradox: When using Profiler the function2 is faster, when not using Profiler the function1 is faster. Significantly different (I run several times to get average)

I would expect that using Profiler would yield an overall extended runtime, because it measures everything going on, but I certainly wouldn't expect the two functions switch place in speed.

Best Answer

The difference is due to the JIT accelerator that kicks in when using the profiler. Same is if you save the script which calculates the running times and call it from cmd window.

Some useful links:

Oleg

Related Solutions

MATLAB: Profiler biases execution time of optimized code

The profiler disables the JIT acceleration of Matlab! This can lead to totally different timings.

Since Matlab 6.5 loops are optimized by the internal JIT-acceleration, such that the repeated calculations are performed much faster. To achieve this, the JIT can reorder the commands of the code. This would confuse the profiler, which looses the relation between code lines and time measurements. In consequence PROFILE disables the JIT completely.

The same behaviour appears, if you enable the debugger by setting a break point. To allow a line-by-line execution, the order of commands/lines must not be modified, and therefore the JIT is disabled, too.

Therefore the PROFILEr, the standard tool for speed optimizations, has a very limited use for optimizing code, which profits from the JIT. Strange, isn't it?

Inserting TIC/TOCs is more reliable.

MATLAB: Matlab issue: Nested while loop paradox

Fraser - just initialize the error epsilon to some value that is greater then R so that the condition

 epsilon > E

is true and the body of the while loop will be evaluated. I think something like the following should work

 no_iter      = 0;
 epsilonError = 2*E;  % renamed to avoid confusion with built-in eps
 while no_iter < max_iter && epsilonError > E
     % calculate xinew
     % calculate epsilonError
     no_iter = no_iter + 1;
 end

Note that I've combined your two while loops into one because you need the two conditions together (as the calculated epsilon may never be less than E and so you will get stuck without the iteration count check).

Also, I am unclear on your calculation for xinew (what is xi?) and the purpose of the line

 if ((abs(xinew-xi)/xinew)*100)

which seems to have something to do with epsilonError.

Best Answer

Related Solutions

MATLAB: Profiler biases execution time of optimized code

MATLAB: Matlab issue: Nested while loop paradox

Related Question