HP Forums

I think we all know that HP's 30b is quite a fast calculator. This is also documented in the calculator benchmark on this site. According to the test using a program that solves the N-queens problem, the 30b is 20-30x faster than the 35s, and the 34s (using the 30b hardware) runs that program even more than 100x faster than the 35s. So far, so good.

I recently acquired two 30b calculators. One of them still runs its original firmware, the other has become a 34s. Here is what I noticed:

• The 30b is really fast. I tried some statistical distributions and their inverses (quantile functions). The results are returned instantly (!) as you browse through the functions catalog. It's essentially the same as using the 34s conversions: the upper line shows the function name, the lower line simultaneously shows the result. As you realize the desired function is selected, the result is already there.

  The same happens with iterative calculations like determining the interest rate of a TVM problem or in a cashflow analysis. The result appears virtually instantly as you press the key.

• Now I tried the same thing on a 34s. Both the Normal CDF as well as the quantile function may require up to two seconds. In a similar way the TVM solver may run for several seconds before a result is displayed. The student quantile may even require five or ten seconds.

• Finally, I used my 35s with its program for the Normal distribution. With a similar approach (two iterations), the quantile requires at most 15 seconds. Since the 34s seems to run 100+ times faster, I would have expected a result within a fraction of a second, similar to a log or trig function on a classic HP. However, the 34s Q^-1 function may take up to full two seconds.
  

Dieter

I can think of a few possibilities beyond the huge number of digits the 34S carries.

The 30b's functions are in C not keystroke programs.

The 30b's functions are specifically written for each function instead of relying on a generic all purpose solver.

The 34s wasn't coded with speed in mind, accuracy and space are more important.

- Pauli

Another reason could be a low battery. The 34s might have switched to slow speed.

SLOW is about 50% of FAST. Execute FAST to make sure it is not running in SLOW mode. The low battery state is indicated in the display.

Harald and Marcus: of course the batteries are new (BATT returns 3,1 V). Phi^-1(0,03) requires 2,4 s in FAST mode and 3,8 s in SLOW mode (timing by means of the TICKS command). Are your units faster?

Dieter

My crystal-less v3.1 build 3324 unit needs 2.8s for this task in FAST mode and 4.5s in SLOW mode - measured by TICKS. BATT returns 3.0V.

But watch it: my v2.2 build 2738 unit (with a crystal built in) needs only 0.6s in FAST mode and 0.8s in SLOW mode, with BATT returning 2.9V.

Marcus?

d:-/

Edited: 7 Dec 2012, 3:54 p.m.

The majority of the difference here is easy.

V2.2 implements the statistical functions in C. V3.1 implements them as keystroke programs. This will be the majority of the difference. V3.1 also has some additional accuracy and stability improvements.

As an aside, I'd expect V2.2 to run keystroke programs faster than V3.1, we made a lot of space saving optimisations in the V3 firmware, many of which cost execution time. With V2.2, flash was pretty much full. Even the most fully featured (printing enabled) V3.1 image is smaller than the V2.2 image. This is despite the many additional features we added. The basic V3.1 image is a full 6kb smaller than the V2.2 image.

- Pauli

Quote:

---

... I'd expect V2.2 to run keystroke programs faster than V3.1 ...

---

d:-)

Walter, but does it matter? I agree that computing times of more than a second for a 'built-in' function (phi^-1) are annoying and can be addressed but the overall speed of the device is still 'good enough'.

TICKS is probably not the best way to measure speed when no crystal is installed. It's better to call the function in a loop and use a stop watch.

A general remark to the execution speed of user (or XROM) code:

- We made the register addressing much more versatile in V3 compared to V2. What used to be a simple array access must now take into account varying register sizes and allocations and needs to cope with local addressing. This adds to each and every register access, even when it goes to the stack.

- If the chip had double the flash size we could make it almost double the speed just by getting rid of thumb mode and all the ridiculously crude space optimizations we did. Alas, the code needs to live in less than 128K... And it does!

Sacrificing library space down to the size of the present library isn't the best idea. The library is meant to be the user's program storage area. The library code provided is just an example what can be done and by no means to be regarded as complete.

Quote:

---

- If the chip had double the flash size we could make it almost double the speed just by getting rid of thumb mode and all the ridiculously crude space optimizations we did. Alas, the code needs to live in less than 128K... And it does!

---

The rule for thumb I've heard is 80% - 160% of the speed and 60% - 70% of the space. It depends on the operations being used and the width of the memory bus. On the 34S we've got wait states accessing flash which will benefit thumb, however we also make extensive use of bit fields (2kb of RAM is painful) which will hurt. Overall in this case, I really don't know.

Still I'll agree that many of the space optimisations we used were very crude but effective. We saved 20% - 30% of available flash for new functions and extra library space.

- Pauli