Re: More extended performance profiling

[John W. Eaton]

On 8/11/19 8:48 PM, Rik wrote:
> I was able to get versions 3.2.4 and 4.0.3 to compile so I have a longer 
> baseline of performance measurements.  Using bm_toeplitz.m, there has 
> been more than 100% slowdown since 3.2.4 to current dev.
>
> *Version* 	*3.2.4* 	*3.4.3* 	*3.6.4* 	*3.8.2* 	*4.0.3* 	*4.2.1* 
> *4.4.1* 	*5.1.0* 	*dev (6.1.0)*
> runtime         5.8968  
>         
>         
>         10.055  10.544  13.052  13.481  13.291

Is there a bug report open where we could track this info?

Please post the changes you made to build 3.2.4 with current tools.  I 
tried but ran into numerous problems and if you have already done the 
work it would save others time in trying to duplicate the issues.

The bm_toeplitz script includes an indexed assignment, a function call, 
and a binary arithmetic operations in the loop.  As a quick check to see 
if just one of these might be the greatest contributing factor to the 
slowdown, could you try simple loops that have only one of these 
features at a time?  For example, try replacing the statement in the 
loop with

  b(k,j) = 13;   ## indexed assignment only, with a constant value

  abs(13);       ## function call only with a constant value (Octave is 
not smart enough to eliminate the call or move it out of the loop)

  abs(k);        ## function call only with one variable value lookup

  k+1;           ## simple binary arithmetic with one variable value 
lookup (Octave is dumb, so it will do this operation every time through 
the loop).

Also, does it matter whether there is more than one index in the indexed 
assignment expression or more than one nested loop?

What happens with an empty loop body?

Using the current sources, is there any significant difference when 
running with the GUI vs. octave-cli?

jwe