[for Gene Wright] HP 35S speed

[Antonio Maschio (Italy)]

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:

LBL A

+

GTO A002

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

LBL A

+

GTO A

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

[Namir]

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.

Namir

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

[Gene Wright]

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:

LBL A

+

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.

[Don Shepherd]

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.

[Antonio Maschio (Italy)]

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

[Les Wright]

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.

Les

[Katie Wasserman]

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).

-Katie