Basic RPL question

[Tugdual]

Welcome in the world of rpl coding, have a lot of fun!

[David Hayden]

Quote:Just read in the manuals where they suggested using local variables instead of global variables for speed and memory reasons

Local variables are implemented as a pointer to the name and a pointer to the object. When you store to a local variable, the calculator just has to update the object pointer.

Global variables are implemented as a copy of the name and a copy of the object. When you store to a global variable, the calculator has to copy the entire object. What's worse, if the size of the new object is different from the size of the old one, then the calculator has to move part of user memory to ensure that the object fits.

So if you're using small objects in your variables and they don't change size (like real numbers) then local and global variables are pretty comparable, but if you store large objects that change size (like lists that grow), then local variables can be much faster.

Quote:Test1: 18.37 seconds
Test2: 2.12 seconds

Wow that's quite a difference. Does anyone know why the algebraic is so much slower? I would have thought that they'd be nearly identical.

[DavidM]

(02-28-2016 11:28 PM)David Hayden Wrote:  

Quote:Test1: 18.37 seconds
Test2: 2.12 seconds

Wow that's quite a difference. Does anyone know why the algebraic is so much slower? I would have thought that they'd be nearly identical.

Keep in mind that those were the total durations for 300 iterations of each program.

I haven't traced through the ROM to see what's happening. But it seems evident that the algebraic has to be parsed and re-sequenced into individual operations before execution can occur. When you consider all that can go into an algebraic (global/local variables, constants, operators, parends, etc.), the logic for that EVAL branch has to be fairly complex. I've always assumed that would be the reason for the relative slowness of evaluating an algebraic vs. direct stack operations.

[wojtek]

(02-28-2016 11:28 PM)David Hayden Wrote:  

Quote:Test1: 18.37 seconds
Test2: 2.12 seconds

Wow that's quite a difference. Does anyone know why the algebraic is so much slower? I would have thought that they'd be nearly identical.

Probably and almost sure because parsing the algebraics takes time. Calculator has to extract variables and operators, arrange them in a proper queue and perform.
The more complicated algebraics the bigger time difference especially if the algebraics is executed in a loop.
A simple optimisation of the code would help here (I mean parsing the expression and storing the result) because the parsing could be performed only once. But unfortunately the code in 50g does not seem to be optimised.
Coding in RPN means the user makes parsing the algebraics and the calculator only executes the operations

[Claudio L.]

(02-29-2016 12:39 AM)wojtek Wrote:  Probably and almost sure because parsing the algebraics takes time. Calculator has to extract variables and operators, arrange them in a proper queue and perform.

I don't think so, algebraics are stored in RPN form, so evaluating simply means running the object as a stream of commands. There's no parsing at run time as far as I can remember.
The speed penalty may come from intermediate results being symbolic, perhaps, or some additional safety checks, I don't know.

[Han]

(02-29-2016 03:48 AM)Claudio L. Wrote:  

(02-29-2016 12:39 AM)wojtek Wrote:  Probably and almost sure because parsing the algebraics takes time. Calculator has to extract variables and operators, arrange them in a proper queue and perform.

I don't think so, algebraics are stored in RPN form, so evaluating simply means running the object as a stream of commands. There's no parsing at run time as far as I can remember.
The speed penalty may come from intermediate results being symbolic, perhaps, or some additional safety checks, I don't know.

I imagine that EVAL has quite a lot of overhead depending on the user's settings (undo settings, lastarg, etc).

[DavidM]

(02-29-2016 03:48 AM)Claudio L. Wrote:  I don't think so, algebraics are stored in RPN form, so evaluating simply means running the object as a stream of commands. There's no parsing at run time as far as I can remember.
The speed penalty may come from intermediate results being symbolic, perhaps, or some additional safety checks, I don't know.

The algebraic is stored in a sequence which resembles an RPN stream, but it is still parsed and re-evaluated when EVAL is invoked.

Case in point (at least on my 50g):

Assuming you have no globals named 'X' or 'Y', enter 'X+Y/2' onto the stack. If you're in Exact mode (system flag 105 clear), the entry will probably* get translated to:

\(X+\frac{Y}{2}\)

Press ENTER to make a duplicate for reference. Then press EVAL and watch what happens:

\(\frac{2\cdot X+Y}{2}\)

...so clearly there is some sort of parsing/re-compiling/reduction operation occurring as a result of EVAL.

*System flags are consulted, which is easy to see if you do the above steps in Approximate mode (system flag 105 set). The results will be different in that mode, and it's entirely possible that other flag settings will affect the outcome as well. I didn't go through every possible combination.