Threaded Mode | Linear Mode

Thomas Klemm · 03-29-2014, 08:51 PM

(03-29-2014 08:07 PM)Tugdual Wrote: Hmmm kinda depend on the version you have now

Could it be from 2013-08? IIRC it was the first official release. Though I only seldom read Prime-related threads I realized that there was a recent bugfix-release. But I don't know whether the emulator was updated as well.
It wasn't possible to copy the release-information as text. Thus I didn't include it in my previous post. And right now I don't have access to the emulator anymore.
But don't worry: the question is barely worth the effort.

Kind regards
Thomas

Tugdual · 03-29-2014, 09:19 PM

(03-29-2014 08:51 PM)Thomas Klemm Wrote:
(03-29-2014 08:07 PM)Tugdual Wrote: Hmmm kinda depend on the version you have now
Could it be from 2013-08? IIRC it was the first official release. Though I only seldom read Prime-related threads I realized that there was a recent bugfix-release. But I don't know whether the emulator was updated as well.
It wasn't possible to copy the release-information as text. Thus I didn't include it in my previous post. And right now I don't have access to the emulator anymore.
But don't worry: the question is barely worth the effort.

Kind regards
Thomas

In order to update (or check version) you may simply start the connection Kit and then in the help menu there is an option to check the latest version.

Gerson W. Barbosa · 03-30-2014, 12:07 AM

(03-28-2014 03:18 AM)bkn42 Wrote: I implemented the two term version of this on my "HP55".
Here is the code (sorry its not in location/keycode form but you get the idea):

Code:

1 - STO 0 0 STO 1 08: X<>Y ENTER ENTER * + 1/x STO + 1 2 STO - 0 RCL 0 0 X<=Y 0 8 RCL 1 GTO 0 0
R0 holds the current iteration and R1 is the series sum.

For N=100, it took about 82sec to finish. Based on this it would take about 2.25hours for N=10000.

The following is a direct conversion of the HP-15C program to calculate pi in the beginning of this thread, so it's rather long: 49 steps, all the programming memory space of the HP-55!

Code:

01 ENTER

02 STO  

03 0

04 STO

05 + 

06 0

07 4

08 STO 

09 1

10 *

11 1/x

12 +

13 1/x

14 STO 

15 2

16 CLx

17 ENTER

18 ENTER

19 Rv

20 Rv

21 1

22 STO

23 -

24 0

25 Rv

26 RCL

27 1

28 CHS

29 STO 

30 1

31 RCL 

32 0

33 /

34 +

35 1

36 STO

37 - 

38 0

39 Rv

40 RCL

41 0

42 2 

43 f

44 x<=y 19

45 Rv

46 Rv

47 RCL

48 2

49 +

66 R/S --> 3.141592654 (2 m 37 s)

Marcel Samek · 03-30-2014, 12:51 AM

(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote: 66 R/S --> 3.141592654 (2 m 37 s)

I took your program and put it on the HP-67. Same result in 1 m 16 s. The other HP-55 program when run on the hp-67 had run a little less than twice as fast, while this ran a little more than twice as fast. With the exception of the label for the goto, the programs are identical.

I assume that the difference is that this program is longer and the penalty for the non-merged instructions is making the difference.

Gerson W. Barbosa · (This post was last modified: 03-30-2014 01:39 AM by Gerson W. Barbosa.)

(03-30-2014 12:51 AM)Marcel Samek Wrote:
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote: 66 R/S --> 3.141592654 (2 m 37 s)

I took your program and put it on the HP-67. Same result in 1 m 16 s. The other HP-55 program when run on the hp-67 had run a little less than twice as fast, while this ran a little more than twice as fast. With the exception of the label for the goto, the programs are identical.

I assume that the difference is that this program is longer and the penalty for the non-merged instructions is making the difference.

I'd better have used another register for summing up the terms rather than the stack. This would save at least two steps inside the loop. No more than some ten second gain, I think (unless some optimization is tried - no idea about though). Even the prefix key takes up one step. This makes 49 steps almost nothing!

bkn42 · 03-30-2014, 03:12 AM

(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote: 66 R/S --> 3.141592654 (2 m 37 s)

My FPGA "HP-55" gets the same answer but in under 1/2 second in turbo mode. Smile

Brian

Gerson W. Barbosa · (This post was last modified: 03-30-2014 04:20 AM by Gerson W. Barbosa.)

(03-30-2014 03:12 AM)bkn42 Wrote:
(03-30-2014 12:07 AM)Gerson W. Barbosa Wrote: 66 R/S --> 3.141592654 (2 m 37 s)

My FPGA "HP-55" gets the same answer but in under 1/2 second in turbo mode.

Brian

Thank you for bringing the HP-55 (and your "HP-55") in here! Funny to see how calculators were like back then. In 1982 I had a TI-59 for a while ( no continuous memory, but it had magnetic card reader), then next year something much better: an HP-15C.
At first I thought you had converted the pi program to the "HP-55" like the previous one for the ln(2) series, judging by the picture in your detailed thread on the "HP-55", but then I realized it was the rational approximation 355/113. This one appears in the small HP-35 manual, BTW.

Regards,

Gerson.

Updated to include hyperlink

bkn42 · 03-31-2014, 04:18 AM

(03-30-2014 03:51 AM)Gerson W. Barbosa Wrote: At first I thought you had converted the pi program to the "HP-55" like the previous one for the ln(2) series, judging by the picture in your detailed thread on the "HP-55", but then I realized it was the rational approximation 355/113. This one appears in the small HP-35 manual, BTW.

Its when I started my HP Calculator FPGA project, I first saw the 355/113 approximation for PI in the HP-35 manual. I used it as a first test of my FPGA design.

On a side note, since there is a lot of execution times being posted here, I tried turning up the internal clock rate of my "HP-55". I never designed it for speed just to be functionally equivalent to the classic HPs. However, I was able to get my current design to run at 84MHz (a 3x increase) -- this is not too bad for the FPGA I'm using. Anyway, all the execution times I posted are now one third of what I stated.

Brian

bkn42 · 03-31-2014, 06:42 PM

I tried the "two-terms-at-a-time" method on my HP-32SII:

Code:

A01 LBL A

A02 0.00002

A03 +

A04 1

A05 -

A06 STO I

A07 0

L01 LBL L

L02 RCL I

L03 IP

L04 ENTER

L05 ENTER

L06 x

L07 +

L08 1/x

L09 +

L10 DSE I

L11 GTO L

L12 RTN

10000 XEQ A
Yields: 0.69309718306 in about 5min 15sec

Brian

Thomas Klemm · 03-31-2014, 07:22 PM

This might be a little faster:

Code:

L04 ENTER

L05 x^2

L06 +

Cheers
Thomas

bkn42 · 03-31-2014, 07:49 PM

(03-31-2014 07:22 PM)Thomas Klemm Wrote: This might be a little faster:

Code:

L04 ENTER L05 x^2 L06 +

Cheers
Thomas

Yes, that is a little faster! Run time now is about: 4min 51secs

Brian

Gerson W. Barbosa · 03-31-2014, 08:01 PM

(03-31-2014 07:22 PM)Thomas Klemm Wrote: This might be a little faster:

Code:

L04 ENTER L05 x^2 L06 +

And this is is a little shorter:

Code:

A01 LBL A

A02 0.00002

A03 +

A04 STO I

A05 0

L01 LBL L

L02 RCL I

L03 IP

L04 ENTER

L05 x^2

L06 -

L07 1/x

L08 -

L09 DSE I

L10 GTO L

L11 RTN

My HP-32SII is slower than Brian's: 5 m 29s here.

Cheers,

Gerson.

Dave Britten · 03-31-2014, 08:27 PM

A very unremarkable version for my Tandy PC-3 (AKA Sharp PC-1251), which uses BASIC:

Code:

10 "L":AREAD C

20 X=0

30 FOR I=C TO 1 STEP -1

40 X=X+(1/I)*((-1)^(I+1))

50 NEXT I

60 PRINT X

70 END

Switch to RUN mode, enter the number of iterations, and press DEF L to start. I get 100 loops in about 32 seconds, so 10000 would take around 54 minutes. Not an especially fast machine.

DavidM · 03-31-2014, 10:13 PM

I was impressed with the timings seen on the 42s and 34s using the "two terms at a time" approach. I didn't think a 50g would do as well, so I thought I'd give it a shot to see what might happen.

UserRPL version:

Code:

\<<

   TICKS

   0

   10000.

   1.

   FOR n

      n DUP 1. - * INV

      +

   -2. STEP

   TICKS ROT - B\->R 8192. /

\>>

Final Value: 0.69309718306
Avg. of 5 runs: 42.745 seconds

I was curious as to how different a SysRPL version of this might be, so I tried the following. I've added comments to (hopefully) make it a bit easier to follow the logic.
SysRPL:

Code:

RPL

DEFINE   TotalLAMs         BINT3

DEFINE   RCL_StartTime     3GETLAM

DEFINE   STO_n             2PUTLAM

DEFINE   RCL_n             2GETLAM

DEFINE   STO_sum           1PUTLAM

DEFINE   RCL_sum           1GETLAM

::

   ( no args required )

   CK0NOLASTWD

   ( place local vars on stack )

   SysTime     ( StartTime )

   %% 10000    ( n )

   %%0         ( sum )

   ( bind local vars )

   NULLLAM TotalLAMs NDUPN DOBIND

   ( loop counter - do [n/2] times )

   RCL_n %%>% COERCE #2/

   ( main loop )

   #1+_ONE_DO (DO)

      ( determine current expression value )

      RCL_n DUP %%1 %%- %%* %%1/

      ( add value to running sum )

      RCL_sum %%+ STO_sum

      ( decrement n by 2 )

      RCL_n %%2 %%- STO_n

   LOOP

   ( convert extended real to user real )

   RCL_sum %%>%

   ( determine run time )

   SysTime RCL_StartTime bit- HXS>% % 8192 %/

   ( release local var bindings )

   ABND

;

Final Value: 0.69309718306
Avg. of 5 runs: 20.318 seconds

Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

Besides the speed difference, the SysRPL version also affords the opportunity to see the 15-digit result of the sum if you don't do the final conversion:
0.693097183059944 (it actually displays as "6.93097183059944E-1"). "Extended Reals" are of no use outside the context of a running SysRPL code object, but it's nice to see all the digits that were retained in the calculations.

Gerson W. Barbosa · 04-01-2014, 02:57 AM

(03-31-2014 10:13 PM)DavidM Wrote: I was impressed with the timings seen on the 42s and 34s using the "two terms at a time" approach. I didn't think a 50g would do as well, so I thought I'd give it a shot to see what might happen.

UserRPL version:

Code:

\<< TICKS 0 10000. 1. FOR n n DUP 1. - * INV + -2. STEP TICKS ROT - B\->R 8192. / \>>
Final Value: 0.69309718306
Avg. of 5 runs: 42.745 seconds

I was curious as to how different a SysRPL version of this might be, so I tried the following. I've added comments to (hopefully) make it a bit easier to follow the logic.
SysRPL:

Code:

RPL DEFINE TotalLAMs BINT3 DEFINE RCL_StartTime 3GETLAM DEFINE STO_n 2PUTLAM DEFINE RCL_n 2GETLAM DEFINE STO_sum 1PUTLAM DEFINE RCL_sum 1GETLAM :: ( no args required ) CK0NOLASTWD ( place local vars on stack ) SysTime ( StartTime ) %% 10000 ( n ) %%0 ( sum ) ( bind local vars ) NULLLAM TotalLAMs NDUPN DOBIND ( loop counter - do [n/2] times ) RCL_n %%>% COERCE #2/ ( main loop ) #1+_ONE_DO (DO) ( determine current expression value ) RCL_n DUP %%1 %%- %%* %%1/ ( add value to running sum ) RCL_sum %%+ STO_sum ( decrement n by 2 ) RCL_n %%2 %%- STO_n LOOP ( convert extended real to user real ) RCL_sum %%>% ( determine run time ) SysTime RCL_StartTime bit- HXS>% % 8192 %/ ( release local var bindings ) ABND ;
Final Value: 0.69309718306
Avg. of 5 runs: 20.318 seconds

Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

There was a mistake in my reply to Werner which has now been fixed (14 minutes 59 seconds, not 14.59 seconds, which means the two terms at a time version might take about 8 minutes). The HP-42S can never be faster than the HP 50g. Sorry for the confusion!

98.85 seconds on my HP-48GX, and 46.97 seconds on my HP 50g, timed with TEVAL:

Code:

%%HP: T(3)A(D)F(,);

\<< TICKS 0 ROT DUP 2

/ 1 SWAP

  START DUP DUP 1 -                         ; on the HP 50g, DUPDUP

* INV ROT + SWAP 2

-

  NEXT DROP TICKS

ROT - B\->R 8192 /

\>>

Gerson.

DavidM · 04-01-2014, 03:54 AM

(04-01-2014 02:57 AM)Gerson W. Barbosa Wrote: ...(14 minutes 59 seconds, not 14.59 seconds, which means the two terms at a time version might take about 8 minutes). The HP-42S can never be faster than the HP 50g. Sorry for the confusion!

I don't own or have access to a 42s, so I wasn't sure. I will confess, however, that I was a bit suspicious about at 14.59 second timing on a calculator with those specs. Wink

Thanks for the clarification.

HP67 · 04-01-2014, 06:50 AM

(03-31-2014 10:13 PM)DavidM Wrote: Not surprisingly, the SysRPL version was noticeably faster. But still not as good as the 42s/34s versions.

If I understood what you did your User RPL version only uses the stack but your Sys Rpl version uses local variables pretty heavily. I would bet the Sys Rpl version could be tweaked to run a lot faster from the stack.

DavidM · 04-01-2014, 08:32 AM

(04-01-2014 06:50 AM)HP67 Wrote: If I understood what you did your User RPL version only uses the stack but your Sys Rpl version uses local variables pretty heavily. I would bet the Sys Rpl version could be tweaked to run a lot faster from the stack.

You might be surprised. Smile

My first attempt at creating the SysRPL version was entirely stack based:

Code:

    SysTime    

    %%0

    %% 10000

    DUP %%2 %%/>% COERCE

    #1+_ONE_DO (DO)

        DUPDUP %%1 %%- %%* %%1/ ROT %%+

        SWAP %%2 %%-

    LOOP

    DROP %%>%

    SysTime ROT bit- HXS>% % 8192 %/

It was very close to the same speed as the local vars version, but very slightly slower. I'm talking about hundredths of a second when averaged over 5 runs. If I ran them both 20 times, I'm not sure which one would have come out ahead. In the end, the local vars version was easier to read (and follow), so I posted that one.

This may not seem intuitive to some, but the use of null-named locals (as I used in the first SysRPL example I posted) as opposed to named locals (which is what you get with standard UserRPL) is significant. Null-named locals are very efficient; they are accessed via an index into a table instead of being searched out by matching a string. This means that recalling/storing null-named variables is very fast. If you can avoid some stack manipulation steps by using null-named local variables, you're likely to see a time savings as a result. Additionally, your code will be much easier to understand and maintain when you can use locals as opposed to manipulating everything on the stack.

In this case, it's nearly even in terms of time. Both versions are fairly easy to understand. In larger projects, it becomes a no-brainer IMHO. When it's close in performance, code clarity (and thus maintainability) wins.

HP67 · 04-01-2014, 09:17 AM

Thank you for the info. From your description of null-named locals it would seem the stack version should still be faster, all else being equal. I'm surprised over 10,000 iterations it didn't have more impact.

DavidM · 04-01-2014, 07:37 PM

(04-01-2014 09:17 AM)HP67 Wrote: From your description of null-named locals it would seem the stack version should still be faster, all else being equal. I'm surprised over 10,000 iterations it didn't have more impact.

Looking at the two versions, the stack version of the loop actually has fewer steps. So I also thought that the stack version would be faster when I first coded it. But the most time-consuming operations in the loop are the computations, not the stack manipulations. Moving pointers around is practically inconsequential when compared to the time involved to compute the inverse of an extended real BCD value (or the sum or product, etc.). The most time-hungry parts of the two loops are exactly the same (-,*,1/x,+,-). That's why the timings are so close; the two versions spend the bulk of their time doing essentially the same steps.

To check my sanity, I did some more testing of these two versions. I created another code object which ran both versions (one after the other) in a loop of 20 iterations. On an emulated 50g (Emu48 1.53+), the stack-based version was faster than the local vars version on 18 of 20 iterations. When I ran the exact same test on my real 50g, the local vars version was faster 16 of 20. In both tests, the differences were minor.

To me, that means that the two versions are so close in speed that other idiosyncrasies of the system (intermittent garbage collection, nibble-alignment, interrupt handling, clock irregularities, etc.) are what's making the difference between the two.