octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: profiling Octave


From: Daniel J Sebald
Subject: Re: profiling Octave
Date: Sun, 11 Aug 2019 00:48:14 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/10/19 5:08 PM, Dmitri A. Sergatskov wrote:


On Sat, Aug 10, 2019 at 1:31 PM Rik <address@hidden <mailto:address@hidden>> wrote:

    I changed the code slightly to make this benchmark file, bm_toeplitz.m

    runs = 5;

    cumulate = 0; b = 0;
    for i = 1:runs
       b = zeros(620, 620);
       tic;
         for j = 1:620
           for k = 1:620
             b(k,j) = abs(j - k) + 1;
           end
         end
       timing = toc;
       cumulate = cumulate + timing;
    end

    ## Total time
    cumulate

    Results are the same as the simpler loop test, about a 25% slowdown
    from 4.2 to 4.4.

    *4.2.1*     *4.4.1*         *5.1.0*
    10.544      13.052  13.481



I compiled 4.2.2  and can confirm that (on i7-2600k):

4.2.2: cumulate =  17.162
6.0.0 (dev: 2c4759c8239c @): cumulate =  21.816


    --Rik


Dmitri.
--

You've picked an instruction format heavily dependent on the efficiency of the interpreter, correct?

Is there any part of Octave around the interpreter engine that has gone from one version to another? (I'm recalling some kind of open-source parser or compiler as one of the libraries included.) That is, is it an Octave issue, or could it be some outside library's issue?

Regarding the interpreting result and how efficient it might be, is there anywhere in the Octave code where one could dump out, say, the size of the interpreter code/instruction list/or anything that might give an indication of efficiency? That is, say there is a point where the parser does it's job, and it is then a case of executing some type of primitive "language". We could then put a printf for the size of the primitive list in both 4.2.1 and 4.4.1.

Using a timer *inside* the code rather than external might help as well. That is, say there is such a point I described above. Printing out times at various locations along the way

Start
End of interpreter
End of execution phase

might reveal something.

One last question, is just-in-time compiling supposed to improve this by cutting down on the amount of interpretation needed in the double looping above?

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]