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: Tue, 13 Aug 2019 01:45:01 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/12/19 5:08 PM, Rik wrote:
On 08/10/2019 09:48 PM, Daniel J Sebald wrote:
[snip]
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?

JWE has changed the parser from a pull parser to a push parser (or maybe
the other way around?) over time.  My hunch is that it is not parsing (done
by lex and bison--old, well-established tools), but evaluation that has slowed.

Yeah, lex.  That is what I was trying to think of.


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.

This is a bit beyond me, but I think so.  I believe Octave constructs a
tree of nodes from the source code and then proceeds to evaluate them.  So
you are correct, if

y = x + 1

generates the same primitive actions

1) create temporary octave_value from scalar 1
2) fetch x
3) perform operator function plus (x, tmp_value)
4) assign octave_value output to y

between versions, but one version takes longer than another, then the
conclusion must be that the individual steps are taking longer.

Interesting about the push/pull parser. Considering steps like above, could reference counting have been affected in some way? Say changing the parser design resulted in the reference count going down to zero when it shouldn't have so that there is more memory reallocation than in the past? Just a theory. Something like memory allocation should be tracked in valgrind, I would think.

Dan



reply via email to

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