50g

I am currently evaluating various hardware and computer languages performance and was curious to see how my HP 50g would fare under the circumstances.
In the normal, plain ordinary RPL, I wrote the following program:

<< -> i j << i j *
TIME 0. 1 j FOR a 1 i FOR b b i / a +
D->R SIN + NEXT NEXT >>
DROP TIME HMS- HMS-> -3600. * / >>

(this little program is similar to the one I used on other implementation, and although it returns nothing as far as calculation, it adds running total so as to defeat an optimizer available in other implementation that would just skip all computations after noticing I am doing nothing of value. This code is functionally similar to the ones used in other systems).

The little program gets the time at the start of the looping phase, and again at the end of it, the total number of iterations is divided by the difference in time, yielding a rough "iterations per second" rating.

So far so good.

The result for the HP 50g is a rather disappointing 15.36 when i and j are set to 10 (i.e. 100 iterations total).
It is disappointing because my vintage HP48SX (with a 2 MHz CPU) returns 16.63 ! How can it be faster than the 75 MHz ARM CPU of the HP 50? Surely the Saturn emulation is not eating away all those cycles?

I have other programs (useful ones, rather than silly do nothing benchmark) and those run significantly faster (5 times or so) on the HP 50 than on the HP48, as they should.

What am I missing here?

> What am I missing here?

Set the calculator to approximate mode and try it again. You are probably using infinite precision integers accidentally (which are naturally going to be much slower) instead of reals.

Also, just use the TEVAL function to do a timed evaluation of the program. Just recall the program on the stack and run TEVAL.

TW

> What am I missing here?

Also, you could see what is going on quite easily by running your program through the built in debugger.

Type 10 10 and then recall your program to the stack. Go into PRG->NXT NXT->RUN and press DBUG. The program can now be stepped through using SST (single step) and you will step through and see what is going wrong.

To make this program better, I modifed it to use the built in timing capability. Observe:

<<
<< -> I J
<< I J * .1 J
FOR A 1. I
FOR B B I / A + D->R SIN
NEXT
NEXT

>>
>> TEVAL DUP UNROT /
>>

Since there is nothing before the second << like a local variable declaration, it silently pushes the program to the stack. This is then evaluated by TEVAL which returns the time. I then make a copy and stick it on level 3, and divide to give the loops per second.

Tried it in approximate mode yet? :-)

TW

--- In 50g@yahoogroups.com, "Tim" <timwessman@...> wrote:

>
> > What am I missing here?
>
> Set the calculator to approximate mode and try it again. You are probably using infinite precision integers accidentally (which are naturally going to be much slower) instead of reals.
>
> Also, just use the TEVAL function to do a timed evaluation of the program. Just recall the program on the stack and run TEVAL.
>
> TW
>

Indeed. I keep it in approximate mode, and somehow, must have reset it, probably when I reflashed the ROM a couple months ago.

Still, the performance only increased to 50, only 3 times faster than the old '48. I was hoping for a bit more, here.


CBVG

--- In 50g@yahoogroups.com, "Tim" <timwessman@...> wrote:

>
> > What am I missing here?
>
> Also, you could see what is going on quite easily by running your program through the built in debugger.
>
> Type 10 10 and then recall your program to the stack. Go into PRG->NXT NXT->RUN and press DBUG. The program can now be stepped through using SST (single step) and you will step through and see what is going wrong.

I used the debugger to ensure the flow of the program was going OK. I am an old timer with the HP48, I bought it -- darn, can't believe it! -- nearly 20 years ago, in 1991. Did a lot of code development on it, prefer its form factor to that of the 50 (the ENTER key has to be on the left side, above the number keys, on a properly designed HP calculator...) and the 48 is a lot gentler on its batteries than the 50 is, even when not in use.

>
> To make this program better, I modifed it to use the built in timing capability. Observe:
>
> <<
> << -> I J
> << I J * .1 J

I assume you meant 1. here

> FOR A 1. I
> FOR B B I / A + D->R SIN
> NEXT
> NEXT
> >>
> >> TEVAL DUP UNROT /
> >>
>
> Since there is nothing before the second << like a local variable declaration, it silently pushes the program to the stack. This is then evaluated by TEVAL which returns the time. I then make a copy and stick it on level 3, and divide to give the loops per second.

You version returns a rating 10% better, a bit higher than the original version.

>
> Tried it in approximate mode yet? :-)

Just did (see previous message).

Still vaguely disappointed at the relatively small gain in performance (3 to 1) when compared with the HP48. I suppose really cranking it up would involve going away from RPL.


CBVG

> Still, the performance only increased to 50, only 3 times faster than the old '48. I was hoping for a bit more, here.

Performance is around 3-7x depending on what you are doing. Some of the internals like memory management and shifiting data around are being done in ARM code, but emulation does take up a lot of CPU time.

TW