[Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch

[Dan Sebald]

Follow-up Comment #12, bug #52809 (project octave):

I'll add another column to the previous times I posted:


octave:1> for lim_p = 0:6
>   lim1 = 10^lim_p;
>   lim2 = 10^(6-lim_p);
>   a = 1; b = 1; t0=tic; for i=1:lim1; for j=1:lim2; end; end; t1=toc(t0);
t1
> end

BEFORE PATCH     AFTER PATCH      AFTER SECOND PATCH
t1 =  0.18503    t1 =  0.18796    t1 =  0.18483
t1 =  0.18548    t1 =  0.18670    t1 =  0.18388
t1 =  0.18704    t1 =  0.18585    t1 =  0.18441
t1 =  0.19305    t1 =  0.18805    t1 =  0.18753
t1 =  0.24489    t1 =  0.21950    t1 =  0.22058
t1 =  0.75854    t1 =  0.53110    t1 =  0.54419
t1 =  5.8472     t1 =  3.5870     t1 =  3.7401



octave:2> for lim_p = 0:6
>   lim1 = 10^lim_p;
>   lim2 = 10^(6-lim_p);
>   a = 1; b = 1; t0=tic; for i=1:lim1; for j=1:lim2; 1; end; end;
t1=toc(t0);
t1
> end

BEFORE PATCH     AFTER PATCH       AFTER SECOND PATCH
t1 =  1.0119     t1 =  0.43711     t1 =  0.39240
t1 =  1.0167     t1 =  0.43716     t1 =  0.39317
t1 =  1.0118     t1 =  0.43754     t1 =  0.39049
t1 =  1.0166     t1 =  0.44116     t1 =  0.39428
t1 =  1.0708     t1 =  0.47755     t1 =  0.43239
t1 =  1.6114     t1 =  0.83763     t1 =  0.77224
t1 =  6.9960     t1 =  4.3774      t1 =  4.1176



octave:3> for lim_p = 0:6
>   lim1 = 10^lim_p;
>   lim2 = 10^(6-lim_p);
>   a = 1; b = 1; t0=tic; for i=1:lim1; for j=1:lim2; a=b; end; end;
t1=toc(t0); t1
> end

BEFORE PATCH     AFTER PATCH      AFTER SECOND PATCH
t1 =  3.1692     t1 =  1.7681     t1 =  1.8105
t1 =  3.1592     t1 =  1.8832     t1 =  1.6622
t1 =  3.1674     t1 =  1.8906     t1 =  1.6655
t1 =  3.1748     t1 =  1.8875     t1 =  1.6682
t1 =  3.2181     t1 =  1.9335     t1 =  1.7094
t1 =  3.7610     t1 =  2.2881     t1 =  2.0454
t1 =  9.0173     t1 =  5.7604     t1 =  5.2106



octave:4> for lim_p = 0:6
>   lim1 = 10^lim_p;
>   lim2 = 10^(6-lim_p);
>   a = 1; b = ones(10000); t0=tic; for i=1:lim1; for j=1:lim2; a=b; end;
end;
t1=toc(t0); t1
> end

BEFORE PATCH     AFTER PATCH      AFTER SECOND PATCH
t1 =  3.2118     t1 =  1.6255     t1 =  1.6648
t1 =  3.2141     t1 =  1.7589     t1 =  1.8495
t1 =  3.2061     t1 =  1.7608     t1 =  1.8414
t1 =  3.2156     t1 =  1.7673     t1 =  1.8461
t1 =  3.2567     t1 =  1.8127     t1 =  1.8916
t1 =  3.7914     t1 =  2.1563     t1 =  2.2721
t1 =  9.1665     t1 =  5.7264     t1 =  5.8135


Observations, going from first patch to second patch:

1) An empty command list case is the same times.

2) The case of a constant within the loop shows 10% improvement.

3) The case of assigning a scalar value to a, i.e., a = b (b=1), shows a 12%
decrease in CPU time, but there is a peculiar increase in the time at the
extreme in which the inner loop is dominant.  **If there is anything to
investigate, it is this result.

4) The case in which there is a large matrix being assigned to 'a' shows a
logical progression of times from small to large as the outer loop becomes
more dominant.

5) Furthermore, note that the times required for large matrix assignment are
now greater than the times for scalar assignment by about 10%.  So, that's a
good result in line with the notion that large matrix transfer requires more
CPU than just transferring a single value.

In summary, 10-12% improvement in the CPU consumption, but something strange
with the evaluation of "a = b" in the inner loop when b is scalar 1 at the
extreme of inner loop dominance.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/