Hi all!
Consider these programs:
(First store 1.999 in C)
| A001 | LBL A |
| A002 | 1 |
| A003 | ISG C |
| A004 | GTO C002 |
| A005 | RTN |
(First store 1.999 in C and 1 in O)
| B001 | LBL B |
| B002 | RCL O |
| B003 | ISG C |
| B004 | GTO B002 |
| B005 | RTN |
Both programs do the same thing: to put number 1 in REGX 1000 times. But, in the HP 35s, program A takes 69 seconds and program B takes 42 seconds, so putting a number in REGX directly is 1.63 times slower than calling a variable.
When I am writing a program for the HP 35s and I need a constant in a loop, I store that constant in a variable and then I recall it in the loop insead of putting the constant directly as a number. With this, execution time is considerably reduced in many situations.
I know that this is not a new topic, others have mentioned it. But I want to know if this happens in other calculators.
Edited: 7 July 2010, 5:56 p.m.
That's been the case since the first machines (HP-65/25/67). The reason is that numeric entry requires the machine to go through entry checking, scaling the value as needed, adding it to a number being created, etc. The overall algorithm is pretty complex. Merely recalling a number takes a simple transfer that's easy.
By the way, your two programs may run at a roughly 1.6:1 speed ratio. However, most of the steps of both programs are similar so the difference of *just the number being loaded* is even greater still.
Back in the day we used to use "E" instead of entering "1" as it was a few clock cycles faster. In the '67, every 7 program steps had a semi-sawtooth execution time overhead. 'Tis amazing how many little tweakes these wonders can take to make them run faster...
All of which gives examples of why compiled programs run so much more quickly as they eliminate much of all this overhead.
Well, here are the "surprizing" results for the HP-32s, optimized by placing subroutines W and Z at the beginning of code.
Factoring 99,999,989 (a prime number)
Old method, using numeric constants 2, 1, 4, and 6: 144 seconds
New method, assigning 2, 1, 4, and 6 to variables A, B, C, and D (outside the loops) and RCL them: 146 seconds
So this would indicate the 32s does not seem to suffer from this malady.
You sure it's not a 1.618 : 1 speed ratio? Ah, another example where the golden mean turns up unexpectedly ;-)
The 32s, 32sii (and many others) pre-process numbers on entry and store them not as keystrokes but in their near final, usable form. That's why you see them as the full number when editing programs rather than as a sequence of digits, one per step. Furthermore, some of these calculators take the trouble to store small integers in a more compact form to save memory instead of using say, 8 bytes for any number they will only use a fraction of a byte.