[for Gene Wright] HP 35S speed


Hi, Gene,

reading up your excellent HP-35S essay found through HPCC, I have a question for you:

You set the program for the HP-35S this way:

GTO A002

and the program for the HP-33S this way:


My question (having no 35s to play with) is: what if you use the exact program of the 33S, that is using a call to label A?
Maybe some optimization occurs with labels calling.

It seems strange to me that the new machine is 2.5x slower than the 33S!

Thanks in advance.

-- Antonio



I did a test by using a loop like the ones you mentioned, but with one difference. I used the multiple operator. I start with a stack filled with the number of 2 and run the program. It took 30 seconds for the version with GTO A002 to display the OVERFLOW error message. The version with GTO A001 took 31.4 seconds. Not much difference for a loop that iterates about 1660 times.


Edited: 25 July 2007, 12:23 p.m.


Thank you very much.

The 35s requires a GTO with a label-line number. GTO A by itself won't work on the 35s.

I tried the same program using GTO A001, and got these results:



GTO A001

only counted to 3344 in 60 seconds. Putting the GTO A002 line back in increased the count to 3584. The differences to the count given in the review may relate to the amount of free memory in the unit now vs. then, or the current distance from the earth to the sun, for all I know. :-)

I don't know for sure, but I would suspect there is increased overhead given the new complex number and vector abilities of the 35s that show up when doing addition (and other math). After all, the 35s now has to check whether one of the values in X or Y is a vector rather than a real number. Just guessing.


Gene, not to mention that for every memory or stack reference, it moves 296 bits (37 bytes *8 bits) into the CPU, instead of (in olden days, anyhow) 56 bits. That's got to be costly.


Well, I didn't think about it, but I guess you're right. The 35S seems to deal with different entities than its ancestors, so a computational stress must be added.

Probably, this is not so important, as long as the calculator is fast enough.

Thanks for your efforts.

-- Antonio



I have noted that the 35s is perceptibly slower for some of my favourite 33s applications, and must share that at first this was a bit disappointing. The 33s has so many headaches and limitations, but at least it was the fastest HP RPN calculator hands down, and that won it a place in my heart. I had hoped that this speed would be inherited unchanged by the 35s.

But I must put this in perspective. Yes a one second calculation on the 33s seems to take about two on the 35s. But the similar program may take up to 30 seconds on the 41CV, and the better part of a minute on the 11C or 15C.

Besides the flexibility introduced by indirect register access and line number addressing (so that alpha labels can be conserved) is fair compensation for the slowing.

I like the complex number capacity, which I find mostly easy to use. I have one routine that computes the sine and cosine integrals for larger arguments by complex continued fraction, and it seems to run faster than the 42S version. I miss the ability to simply decompose a complex number in rectangular form into its real and complex parts, but the proposed workaround (Re(z) = abs(z)*cos(arg(z)) and Im(z) =abs(z)*sin(arg(z))) is not hard to program.

The ability to recall certain stack levels directly by accessing REGX, REGY, REGZ, etc., by way of EQN Rv is reminiscent of RCL ST X, etc., of the 41 series and 42S and can be very useful at times, though I must I would have appreciated fully appointed stack register arithmetic like in those older machines. STO+ ST X is a great way to double the contents of the X register without molesting the stack, and I wish the 35S had that capacity.

I can get to like the vector capacity, but I think it is not straightforward to compose a vector from stack input. It can be done in an equation, and it may be prudent to write a subroutine to do this automatically. It is, however, easy to isolate a component--on simply dot multiplies the vector by the relevant unit vector--e.g., [3,4,5]*[0,1,0] = 4. Being able to isolate individual vector components like this is useful when one wants to increase storage capacity by put, effectively, three real numbers in each register.

So far, a real winner. I look forward to seeing how the special features influence programming style.



Simple program changes can make a dramatic difference on the 35s. In particular: DON'T USE CONSTANTS INSIDE LOOPS. Try a simple count test:

A001 LBL A
A002 1
A003 +
A004 GTO A002

This will count to 1442 in 60 seconds.

A001 LBL A
A002 1
A003 STO A
A004 RCL A
A005 +
A006 GTO A004

This will count to 2939 in 60 seconds (twice as fast).

A001 LBL A
A002 1
A003 STO A
A004 RCL+ A
A005 GTO A004

This will count to 5157 in 60 seconds (almost twice again as fast, but not a fair comparison since there's one less instruction in the loop).


Possibly Related Threads...
Thread Author Replies Views Last Post
  48G vs 49G+ User RPL Speed Comparison John Colvin 7 1,197 11-16-2013, 10:07 PM
Last Post: Han
  WP-34S: Speed of y^x Marcel Samek 1 567 09-14-2013, 07:31 PM
Last Post: Paul Dale
  WP-34S function execution speed ? Gene Wright 4 842 09-04-2013, 05:40 PM
Last Post: Paul Dale
  HP-27S speed compared to HP-42S Tommi 3 888 06-05-2013, 05:55 PM
Last Post: Christoph Giesselink
  HP-39gII speed Mic 2 784 02-24-2013, 05:55 PM
Last Post: Thomas Klemm
  Calculator Speed Benchmark (Add Loop) Thomas Chrapkiewicz 2 754 01-20-2013, 11:24 AM
Last Post: Thomas Chrapkiewicz
  Speed comparison: HP 30b vs. WP 34s Dieter 9 1,321 12-08-2012, 04:34 AM
Last Post: Paul Dale
  Gene, are you out there? Dieter 8 1,128 10-19-2012, 12:04 PM
Last Post: Dieter
  Question to Eric Rechlin & Gene Wright about HP30b/30b repurposing at HHC2012 Namir 2 640 08-04-2012, 05:30 PM
Last Post: Namir
  Programming cable for hp-30b -> wp-34s Open letter to Gene Nigel Rowe 37 4,595 08-02-2012, 12:30 AM
Last Post: Guy Dufour

Forum Jump: