Summation based benchmark for calculators

[grsbanks]

(10-07-2020 08:08 PM)Frido Bohn Wrote:  fast mode, battery powered: result=139.2971873, time 14.33 s
fast mode, USB connected: result=139.2971873, time 4.61 s

The FOCAL program was beginner level, i.e., not streamlined to stack-only operations.

By doing just that (using just the stack) a while back when I first benchmarked the DM41X, I got it to do 100 iterations in 3.85s when on USB power and in 12.09s on battery power.

[Frido Bohn]

(10-08-2020 10:39 AM)grsbanks Wrote:  By doing just that (using just the stack) a while back when I first benchmarked the DM41X, I got it to do 100 iterations in 3.85s when on USB power and in 12.09s on battery power.

Thanks for the info. So it is an about 20% increase of speed. I am curious how this would result in MCODE. Probably the gain would not be that much as long as the built in irrational functions are used which are accessed through FOCAL as well.

[Mjim]

Recently obtained an fx-3600pv (circa 1989/90), which needed a bit of cleanup and repair (segment problems). Considerably faster than the fx-50F, with 38 steps and a bigger LCD display, but fairly stripped down in terms of features (No formulas, no constants).

The integration is a nice feature though and is well implemented for a Simpson version, including the trimming of inaccurate digits. It was hysterical that my fx-991MS 2nd Edition that came out last year is only ~25% faster and gives the exact same answer! (78 vs 62 seconds integrating e^(x^2) from 0 to 10 using 512 divisions). Of course now the newer integration technique that Casio uses is vastly more accurate and faster, though I was surprised at how well it works on this old fx-3600pv.

It has some bugs in programming as I verified having the same problem as in this rskey.org article:
http://www.rskey.org/fx3600pv

It also uses only 11 digits of precision (vs 12 on the fx-50f), which causes problems with Casio's weird rounding system:
https://translate.google.com/translate?h...ch&pto=aue

Basically if the last 2 digits + 11th hidden digit end in 001 -> 007 it rounds down to 000, which means for the number 1,234,567,800 any added decimals between 0.1 -> 0.7 don't count, which is just bizzare (you can add 0.7 as much as you like, but it wont change the answer). It will also do the same for 993 -> 999 except rounding up.

Also there isn't enough precision for handling powers, ie 2^33 = 8,589,934,592, but the fx-3600pv instead returns 8,589,934,589 which is off by 3, exceeding Casio's stated accuracy of +-1 digit on the 10th digit. This isn't just a problem for the fx-3600pv, but seems a widespread problem with any of the old Casio's using 11 digits of accuracy (verified on the fx-550s and the fx-82LB - though that is only 8 digits, so not so much of a problem).

In any case, probably too much commentary, here are the figures:

Summation Benchmark n=10:
Average of 3 tests (Degrees): 6 seconds
Result: 13.711835009

Summation Benchmark n=100:
Average of 3 tests (Degrees): 58.9 seconds
Result: 139.2971869

Summation Benchmark n=1000:
Test 1 (Degrees): 573 seconds
Test 2 (Radians): 574 seconds
Result: 1395.3462707 (same for both tests, whether degrees or radians)

It's much faster than the fx-50f (~3 times), but it isn't as accurate.

EDIT: I should add that this was well lit, next to the window on an overcast, but bright day. While I also have a brand new silver oxide battery in both the fx-50f & fx-3600pv, it does take longer when moved away from a light source (~74 instead of 58 seconds on my desk just testing now). It was also mentioned above that in some cases the cube root vs the x^(1/y) power function can produce different results, but they seem to be about the same on this old Casio. The square and root function are actually much faster on the Casio then using the x^(1/y), but that wasn't used for this benchmark.

[Michael de Estrada]

(10-08-2020 10:39 AM)grsbanks Wrote:  

(10-07-2020 08:08 PM)Frido Bohn Wrote:  fast mode, battery powered: result=139.2971873, time 14.33 s
fast mode, USB connected: result=139.2971873, time 4.61 s

The FOCAL program was beginner level, i.e., not streamlined to stack-only operations.

By doing just that (using just the stack) a while back when I first benchmarked the DM41X, I got it to do 100 iterations in 3.85s when on USB power and in 12.09s on battery power.

I get slower times with coding that uses storage registers and the TIME function to compute the elapsed time, rather than a stopwatch:

LBL <t>SPEED
STO 10
TIME
HR
STO 00
0
STO 11
1
STO 12
LBL 01
ATAN
SIN
E^x
3
1/X
Y^x
ST+ 11
RCL 12
1
+
STO 12
DSE 10
GTO 01
TIME
HR
RCL 00
-
3600
*
END

My results are:

fast mode, battery powered: result=139.2971873, time 16.36 s

fast mode, USB connected: result=139.2971873, time 5.36 s

[Xorand]

Some more TI nspire CX II CAS results.
Hardware version M-0720AK (2020), OS 5.2.0.771 (2020)

Using the sum function in approx. mode, I got the same results as an earlier poster for 100,000 iterations:

Sum function, approx. mode - ~95 sec., 139561.

Using the built-in python for 100,000 iterations:

python script - ~19.5 sec., 139560.9761410522

Code:

from math import *
def RunTest(n):
  x=0
  for i in range(1,n+1):
    x=x+pow(exp(sin(atan(i))),1/3)
  print(x)

[BINUBALL]

I've tested fx-570EX for benchmark.
It's very similar to fx-991EX but there is no solar panel. It uses 1 AAA battery for power so It may be a few faster than fx-991EX.

max = 1000
~ 109s - casio fx-570EX, 1395.346288 sum function
max = 100
~ 12s - casio fx-570EX, 139.297187 sum function
max = 10
~ 2s - casio fx-570EX, 13.71183502 sum function

After test, there are not noticeable difference with fx-991EX. So I tried max = 10000
max = 10000
~ 1073s - casio fx-570EX, 13955.8579 sum function

And I tried to max = 100000, It may take 2 hours..

[BINUBALL]

I did it!
max = 100000
~ 1h 58m - casio fx-570EX, 139560.9761 sum function
It runs 16:26 ~ 19:24

[ttw]

I tried the sum of the cube root of the exponential of the arctangent of the sine of N (I think) on my HP Omen Laptop (last year's model). I wrote it in Silverfrost Fortran in debugging mode as I can't get Emu48 to work on Windows 10.

Loop limit, 100,000,000. Timer 12 secs. Assuming about 5 flops per function (or so) this seems about 3 times faster than the Cray-1 from 1975. A bit slower than the 1982 Cray XMP which had 1 gig SSD. Memory was smaller though about 64 megabyte.

The problem with high-speed computing isn't in building high-speed CPUs; the problem is feeding them. We used to tell buyers that a $32,000,000 computer had a $1,000,000 CPU, a $1,000,000 Memory and a $30,000,000 switching network.

[toml_12953]

I find it interesting that this runs in 0.748 sec on a G2 Prime (N=10000)

Code:

EXPORT RunTest(N)
BEGIN
Σ(3 NTHROOT (e^(SIN(ATAN(X)))),X,1,N);
END;

but this:

Code:

EXPORT RunTest(N)
BEGIN
Σ(3 NTHROOT e^(SIN(ATAN(X))),X,1,N);
END;

runs in 0.93 seconds. The extra parentheses help.

[Guenter Schink]

HP XPANDER
max=1000
\[ \sum_{x=1}^{1000} \sqrt[3]{e^{ sin \left (atan(x) \right ) }} \]
ca. 12 sec 1395.34628774

max=10000
\[ \sum_{x=1}^{10000} \sqrt[3]{e^{ sin \left (atan(x) \right ) }} \]
ca. 97 sec 13955.8579043

Günter

[Xorand]

TI-82 - 0497 Date Code

Iterations=1000
Time=~115s
Result=1395.346288

Program taken from earlier post:

Code:

:Prompt N:0
:For(X,1,N,1)
:Ans+cube_root(e^(sin(atan(X))))
:End:Ans

[ttw]

Emu48 using flat HP50 on Samsung S9+

<< 1.3 3. / -> A
<< 0. 1. 10000. FOR J J ATAN SIN EXP A ^ + NEXT >> >>


N: 10,000
Sum: 13955.8578444
Time: 3.2925 seconds (from TEVAL)

[John Keith]

Amusingly, I ran the benchmark last night on the same model phone. I used the program from post # 47 and I got
339 milliseconds for 1000
3.295 seconds for 10,000
32.0 seconds for 100,000.

On an older Windows 7 laptop (Core i5 2.4Ghz.) I got 4.93s and 48.2s respectively. Using XROOT instead of 3. INV ^ decreased run times by about 2%.

On my newly acquired HP-28S, I get 13.2 seconds for 100, 123 seconds for 1000.

[ttw]

(03-23-2021 06:40 PM)John Keith Wrote:  Amusingly, I ran the benchmark last night on the same model phone. I used the program from post # 47 and I got
339 milliseconds for 1000
3.295 seconds for 10,000
32.0 seconds for 100,000.

On an older Windows 7 laptop (Core i5 2.4Ghx.) I got 4.93s and 48.2s respectively. Using XROOT instead of 3. INV ^ decreased run times by about 2%.

On my newly acquired HP-28S, I get 13.2 seconds for 100, 123 seconds for 1000.

The phones seem close. I'd try EMU48 on the windows machine but I haven't got it to work yet. (I wanted the HP50g stuff for the big integers.)

[ttw]

Rewriting the inner loop as J DUP 2.* 1. + SQ 3. * / EXP shortens the S9+ down to 1.9535 seconds for 10,0000. It's no longer a comparable benchmark but it does illustrate that algorithm trumps hardware.

Back in 1975, Datamation had an article about the speedup in solving partial differential equations. From 1945 the speedup had been about 10^25. The hardware speedup was about 10^10 (Friden electrical calculator) and about 10^15 from software (Gauss-Seidel to Fast Fourier Transform methods, known by Gauss, of course.) To be fair, the speed of the Fast Fourier Transform only begins to pay off in big systems.

[Eric Rechlin]

Using the program from post 47, on a Galaxy S20+ with Emu48 (emulated 50g), I get 100,000 iterations in 17.3 seconds. On my Core i7-4790K computer with Windows 10 and Emu48 (emulated 50g), I get 100,000 iterations in 26.1 seconds.

It's crazy how modern phones are faster than even fairly high end computers. And Emu48 is single-threaded, so we are only looking at single core performance, of which the 4790K still is quite competitive with high-end brand-new CPUs (single thread Passmark score of 2469, vs 3741 for the fastest CPU tested, the i9-11900K).

[John Keith]

I wonder if the speed difference might have to do with processor architecture. The hp 50g ROM is code that runs on an ARM processor. Perhaps the code translates better to ARM-based cell phone chips than to the vastly different Intel processors.

[Eric Rechlin]

(03-25-2021 08:57 PM)John Keith Wrote:  I wonder if the speed difference might have to do with processor architecture. The hp 50g ROM is code that runs on an ARM processor. Perhaps the code translates better to ARM-based cell phone chips than to the vastly different Intel processors.

No, because the 50g ROM used in Emu48 has no ARM code and is purely Saturn code. So maybe the code of Emu48 to emulate the Saturn just happens to run better on ARM chips than x86 chips?

[John Keith]

You are correct, of course. I misspoke.

[Hollerith]

TI-67 released 1992

n=10
program ~15secs 13.71183502
sum func ~11secs 13.71183502

n=100
program ~146secs 139.297187
sum func ~105secs 139.297187

Casio fx-4500p released 1989

n=10
program ~9secs 13.71183502

n=100
program ~88secs 139.297187