HP 42S Version Speed Variation

[Gerald H]

(06-11-2014 07:37 AM)J-F Garnier Wrote:  

(06-10-2014 05:37 AM)Gerald H Wrote:  I have checked against the programmes as stored in my HP 42S & the coding is identical - my calculators produce correct factorizations.

Please check your coding again, as errors do occur - see my previous post & the initial posting on this matter.

Gerald,
For the sake of completeness, I run your programs on my physical A and C machines.
I got:
version A machine: 414s
version C machine: 432s
consistent with the observation that version A is slightly faster (+5%).

I assume that there is something different in the implementation of your programs in your C machine.
Can you please check again? - Errors do occur :-)
Only you can do it since you are the only one to get such a speed difference (40%).

Please share your findings, I'm now curious...

J-F

Entered progs on the 2 machines are identical.

I am the only one to record a large difference in performance, but then the sample is very small.

I have frequently used the prog "FAST" on the version A machine, but these tests were carried out in the standard state, ie "FAST" was not operating.

Can repeated use of "FAST" have some permanent effect?

What are the serial numbers of your calculators?

[J-F Garnier]

(06-11-2014 09:43 AM)Gerald H Wrote:  Entered progs on the 2 machines are identical.

I believe you. And the "mystery" of your longer execution time can be explained, easily. Check carefully :-)

Quote:I have frequently used the prog "FAST" on the version A machine, but these tests were carried out in the standard state, ie "FAST" was not operating.

Can repeated use of "FAST" have some permanent effect?

Gerald, your version A machine execution time is normal, see my tests. It's your version C machine execution time that is longer. Check it :-)
Hint: I didn't say that your version C machine is slower.

[Gerald H]

(06-11-2014 11:28 AM)J-F Garnier Wrote:  

(06-11-2014 09:43 AM)Gerald H Wrote:  Entered progs on the 2 machines are identical.

I believe you. And the "mystery" of your longer execution time can be explained, easily. Check carefully :-)

Quote:I have frequently used the prog "FAST" on the version A machine, but these tests were carried out in the standard state, ie "FAST" was not operating.

Can repeated use of "FAST" have some permanent effect?

Gerald, your version A machine execution time is normal, see my tests. It's your version C machine execution time that is longer. Check it :-)
Hint: I didn't say that your version C machine is slower.

New test of 11th repunit on HP 42S 3123S01777, version C, confirms your suspicion - time taken was 428s.

I don't understand the hint - 3144S06635 must be much slower in execution, implying the machine IS slower.

[J-F Garnier]

(06-11-2014 12:37 PM)Gerald H Wrote:  I don't understand the hint - 3144S06635 must be much slower in execution, implying the machine IS slower.

You previously confirmed that short loop tests show that there is no significant speed difference. And BEEP indicates that the system clock is normal. So the machine IS NOT slower.

Don't assume your machine is slower, check why you have longer execution time on this machine.

You have an advantage over me: you have your machine in front of you to experiment. I only had my brain to elaborate a solution to this enigma :-)

[rprosperi]

(06-09-2014 02:56 PM)Thomas Klemm Wrote:  

(06-09-2014 02:12 PM)rprosperi Wrote:  Thomas - Is there a way to create these individual post# links automagically, or only crafting them by hand (insert thread link then edit to add post#)? Quite useful and elegant way to save space in complex replies.

You can right-click the number of the post in the top right corner,
choose [Copy Link Location] in the context-menu
and then create a link in the toolbar [Insert hyperlink]:

I can't reference only this icon but it's the earth and the chain.

You can even add a highlight url-parameter: #19.

Cheers
Thomas

PS: In the old forum you had to search for the id of a post in the source in order to directly link to a certain post.

Thanks very much Thomas. Using the insert URL is simple, works well and even offers a label if no quoted text, but I could not get the post link #. I assumed this would work as you say, but it failed (no address would pop-up) because i right-clicked on "Post" and not on "#NN". Devil is always in the details.

[Gerald H]

(06-11-2014 01:00 PM)J-F Garnier Wrote:  

(06-11-2014 12:37 PM)Gerald H Wrote:  I don't understand the hint - 3144S06635 must be much slower in execution, implying the machine IS slower.

You previously confirmed that short loop tests show that there is no significant speed difference. And BEEP indicates that the system clock is normal. So the machine IS NOT slower.

Don't assume your machine is slower, check why you have longer execution time on this machine.

You have an advantage over me: you have your machine in front of you to experiment. I only had my brain to elaborate a solution to this enigma :-)

In the historically titanic clash of Brain v Propinquity I hope/believe Brain wins out.

In other words, I'm at a loss for any explanation. After a new self-test, stating machine reset, the usual 11th repunit seed & following factorization scored 611s.

My laziest conclusion is that the short loop tests do not in any way really stress the calculator, whereas the factorization does.

[Mike Morrow]

(06-11-2014 02:31 PM)Gerald H Wrote:  My laziest conclusion is that the short loop tests do not in any way really stress the calculator, whereas the factorization does.

One may obtain grossly different relative speeds of calculation depending on the benchmark used. I can use the simple loop benchmark and show that Free42 on my Android is 8000 times faster than a real HP 42S, or I can use the Savage Benchmark and show that Free42/Android is a mere 400 times faster than a real HP 42S! The simple loop benchmark is a fool's benchmark. Nor do I like the pointlessly popular N-queens benchmarks...they do not produce valid comparison results for scientific-oriented calculations.

For many years (more than 30 years ago) the Savage Benchmark was commonly used to test a PC's compiler or interpreter speed and accuracy and the effects of improved hardware like a faster clock or math co-processor addition, or an alteration of precision. A process that made heavy use of common scientific functions and their inverse functions is the most useful benchmark for scientific evaluation. The Savage Benchmark remains rather useful today for scientific calculators.
Radian mode. X=0. Perform next line 2500 times:
X = tan(atan(e^(ln((sqrt(X+1))^2))))
The time it takes to complete 2500 iterations is a benchmark for speed.
The amount that the end result varies from a perfect 2500.0000000 is a benchmark for accuracy.

***
NB: There is a slightly different version of the Savage Benchmark that is flawed in construction, compared to that described above and programmed below. The flawed construction was forced by limitations of BASIC language structure in standard interpreters or compilers that made it easier to program this Savage version:
Radian mode. X=1. Perform next line 2499 times:
X = tan(atan(e^(ln((sqrt(X^2))))) + 1

Calculator language structure (even TI's) is much more flexible and need not utilize the flawed construction.
***

For the HP 42S, here is a version of the Savage Benchmark:

01 LBL "SB"
02 RAD
03 0
04 LBL 01
05 1
06 +
07 SQRT
08 X^2
09 LN
10 E^X
11 ATAN
12 TAN
13 DSE ST Y
14 GTO 01
15 BEEP
16 DEG
17 END

Enter "2500" in X, push "SB" and start external timing device.

RESULTS:
Rev A ROM HP 42S (2934Sxxxxx): 2499.99946106 in 591 seconds.
Rev C ROM HP 42S (3328Sxxxxx): 2499.99946106 in 609 seconds.

The numerical results are identical. The speed result difference is negligible...all that can be concluded is that this particular ROM A machine is 3 percent faster than this particular ROM C machine.

[Paul Dale]

(06-13-2014 04:23 AM)Mike Morrow Wrote:  The amount that the end result varies from a perfect 2500.0000000 is a benchmark for accuracy.

Insert another discussion about correct rounding and how 2500 isn't the expected result on any finite precision floating point device

In single precision mode, the 34S gets 2500.000000006559. This is most likely the true correct result for a sixteen digit decimal device.


- Pauli

[Mike Morrow]

(06-13-2014 04:55 AM)Paul Dale Wrote:  

(06-13-2014 04:23 AM)Mike Morrow Wrote:  The amount that the end result varies from a perfect 2500.0000000 is a benchmark for accuracy.

Insert another discussion about correct rounding and how 2500 isn't the expected result on any finite precision floating point device

In single precision mode, the 34S gets 2500.000000006559. This is most likely the true correct result for a sixteen digit decimal device.

heh heh! My brain hurts!

In a "perfect" world with perfect infinite precision calculators, little details like floating point arithmetic would vanish or be banished. For now...let's just use truncation and rounding to get that perfect (looking) result! :-)

[J-F Garnier]

(06-13-2014 04:23 AM)Mike Morrow Wrote:  One may obtain grossly different relative speeds of calculation depending on the benchmark used.

Well, it's true when comparing different machine/language/OS but with the same hardware/software environment the comparison is largely code-independant. That's why the simple-loop test is enough to estimate the relative speed difference.

Quote:RESULTS:
Rev A ROM HP 42S (2934Sxxxxx): 2499.99946106 in 591 seconds.
Rev C ROM HP 42S (3328Sxxxxx): 2499.99946106 in 609 seconds.

The numerical results are identical. The speed result difference is negligible...all that can be concluded is that this particular ROM A machine is 3 percent faster than this particular ROM C machine.

This is another, independent indication that there is no significant speed difference between HP-42S software versions (version A only slightly faster than version C).

J-F