In support of the 33s & 35s

[Dieter]

(01-04-2018 01:21 PM)pier4r Wrote:  Thanks for the test and the result still baffles me.

Ok for the memory usage, I don't mind it. Anyway the execution is something that I cannot yet understand.

Then take a look at the results below. ;-)

First of all, I think I was wrong about the memory usage of numeric constants. My knowledge essentially was what BartDB said: any numeric constant takes 37 bytes. But I think this is wrong and the 37 bytes refer to the memory used by the data registers, including the 800 indirect ones on the 35s. For numbers in programs it looks like it's actually 3 bytes plus one more byte for each digit / decimal point / E / sign. So a simple "3" requires four bytes. Regular 33s/35s commands occupy 3 bytes, so "pi IP" is 6 bytes, i.e. two bytes more than a plain 3.

But indeed the execution speed significantly varies with the way constants are used in 35s programs. Here is an example with 100 loops of adding 3√3+3 where the constant "3" is coded in different ways:

Code:

B001 LBL B
B002 100
B003 STO C
B004 CLSTK
B005 3
B006 SQRT
B007 3
B008 x
B009 3
B010 +
B011 +
B012 DSE C
B013 GTO B005
B014 RTN

This straightforward, plain vanilla code runs in about 17,5 s.

Next version:

Code:

B001 LBL B
B002 100
B003 STO C
B004 CLSTK
B005 pi
B006 IP
B007 SQRT
B008 pi
B009 IP
B010 x
B011 pi
B012 IP
B013 +
B014 +
B015 DSE C
B016 GTO B005
B017 RTN

Replacing the number "3" with pi IP speeds up the program:
The above code runs in about 14 s.

Here's another version, this time using LastX:

Code:

B001 LBL B
B002 100
B003 STO C
B004 CLSTK
B005 3
B006 SQRT
B007 LastX
B008 x
B009 LastX
B010 +
B011 +
B012 DSE C
B013 GTO B005
B014 RTN

Avoiding two out of three numeric constants gives a significant boost compared to the first version:
The above code runs in only 13 s, comparable to the previous pi IP version, but requiring two steps less per loop which may account for the slight difference.

And yet another version:

Code:

B001 LBL B
B002 100
B003 STO C
B004 3
B005 STO 7
B006 CLSTK
B007 RCL T
B008 SQRT
B009 RCL T
B010 x
B011 RCL T
B012 +
B013 +
B014 DSE C
B015 GTO B007
B016 RTN

Using RCL and avoiding inline numbers completely speeds up the program even more.
The above code requires just about 10 s.

And finally this one:

Code:

B001 LBL B
B002 100
B003 STO C
B004 3
B005 STO T
B006 CLSTK
B007 RCL T
B008 SQRT
B009 RCLxT
B010 RCL+T
B011 +
B012 DSE C
B013 GTO B007
B014 RTN

Using RCL-Arithmetics saves two lines and squeezes out one more second.
The above code now runs in about 9 s.

So it looks like you can almost double the execution speed of this program by choosing the right method that best fits the 35s.

Finally, here is another example with three different numeric constants:

Code:

B001 LBL B
B002 100
B003 STO C
B004 CLSTK
B005 3
B006 SQRT
B007 2
B008 x
B009 1
B010 +
B011 +
B012 DSE C
B013 GTO B005
B014 RTN

The standard version runs in about 17,5 s just as the first program. This could be expected as only the values of the three constants are different.

Now try replacing 3, 2 and 1 with other commands:

Code:

B001 LBL B
B002 100
B003 STO C
B004 CLSTK
B005 pi
B006 IP
B007 SQRT
B008 e
B009 IP
B010 x
B011 pi
B012 SGN
B013 +
B014 +
B015 DSE C
B016 GTO B005
B017 RTN

Although this version has more steps per loop, avoiding the three numeric constants and replacing them with IP(pi), IP(e) and sign(pi) yields a speedup which makes the program finish in merely 13,5 seconds. Finally an "ENTER +" instead of the multiplication saves another second so that we get below 13 s.

Now, why are regular inline numbers so slow? I suspect this is because they are handled as equations. This would also match their memory usage (3+n bytes). Equations have to be parsed each time the program comes across one, and this requires some time.

(01-04-2018 08:38 AM)grsbanks Wrote:  

(01-04-2018 08:06 AM)Dieter Wrote:  LBL C is not required, the 35s can branch to any program line. So remove LBL C and GTO B007 instead. This way the loop also is one step shorter.

And a lot faster in execution time because the 35s doesn't have to search through program memory for the LBL at each GTO (it isn't cached in the 35s).

I don't think that removing the second label from Antonio's code yields any significant speedup (except for one step less per loop) as the 35s does not search labels the way classic HPs did: there is no "GTO C", i.e. "search for label C and continue there". The code is "GTO C001", i.e. "branch to line 001 of program C". So I don't think there is a speed difference between "GTO C001" and "GTO B007". In both cases it's (more or less) direct line addressing.

Dieter

Edit: corrected a few listings, especially line numbers