HP Forums

Full Version: Speed Comparison.
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Lovers :-)            Sec. Author
-------------------------------------------
FX-4500PA 1220 Xerxes
HP-15C 5104 Gerson W. Barbosa
HP-41CV 1120 Xerxes
HP-41CY (TURBO OFF) 1080 Gileno
HP-42S 806 Gerson W. Barbosa
PB-2000C "C" 572 Marcus von Cube
HP41CY (TURBO ON) 520 Gileno
PC-1360 480 Gileno (8-bit 768 KHz)
PC-1261 441 Chris Roccati (8-bit)
HP-32SII 388 Gerson W. Barbosa
HP-32S 262 Albert Graef
HP-33S 251 Gerson W. Barbosa
FX-5800P 234 Xerxes
PC-1248 172 Chris Roccati (4-bit 1 MHz)
FX-603P 165 Xerxes
HP-71B Version 2CDCC 153 John Pierce
TI-74 139 Marcus von Cube
FX-7000G 127 Palmer O. Hanson, Jr
PC-1600 110 Gileno (Z80A)
TI Voyage 200 106 Maximilian Hohmann
FX-7500G 96 Xerxes
FX-603P [turbo 2.0] 83 Xerxes
HP-50g 81 Albert Graef
Psion Organaizer II XP 62 Chris Roccati
CZ-1GR "Basic" 59 Marcus von Cube
Model 100 57 Palmer O. Hanson, Jr.
75C Version aaaaaa 47 Gileno
75D Version aaaaaa 44 Gileno
75D Version dddddd 32 Gileno
FX-7500G [turbo 3.3] 29 Xerxes
FX-9860G 21 Xerxes
Z-1GR "C" 14 Marcus von Cube

Basic Listing
-------------
5 CLEAR
10 R=8
20 REM DIM A(R)
30 S=0
40 X=1
50 A(X)=R
60 IF X=R THEN 200
70 X=X+1
80 A(X)=R
90 S=S+1
100 Y=X
110 Y=Y-1
120 IF Y=0 THEN 60
130 T=A(X)-A(Y)
140 IF T=0 THEN 160
150 IF X-Y<>ABS(T) THEN 110
160 A(X)=A(X)-1
170 IF A(X)<>0 THEN 90
180 X=X-1
190 IF X<>0 THEN 160
200 PRINT S
210 BEEP 1

FoCal Listing
-------------
LBL_A
CLX STO_11
8 STO_12 STO_01
1 STO_00
LBL_00
RCL_00 RCL_12
X=Y? GTO_04
ISG_00 DEG
STO_IND_00
LBL_01
ISG_11 DEG
RCL_00 STO_10
LBL_02
DSE_10 DEG
RCL_10 X=0? GTO_00
RCL_IND_00 RCL_IND_10 -
X=0? GTO_03
ABS RCL_10 + RCL_00 -
X<>0? GTO_02
LBL_03
DSE_IND_00 GTO_01
DSE_00 GTO_03
LBL_04
RCL_11
BEEP


Edited: 3 Feb 2007, 9:56 p.m. after one or more responses were posted

Quote:
HP-32S                 266 Albert Graef

Make that 262, the value that I reported first was inaccurate, see this post.

Quote:
HP-50g                 108 Albert Graef 

I think it would be fair to give the 81 secs of the recursive solution here, as it's actually more RPL'ish than my lame iterative implementation, while still implementing the original algorithm. And who would actually believe that the 50g is slower than the v200 on this problem? ;-) It should be interesting to compare the two using the C version of the algorithm, the 50g's 75 MHz ARM should run circles around the v200's 68k cpu. Alas, I currently lack the time to do this.

There are utilities out there to push the 50g CPU up to 203 Mhz. You add a step to call this ARM routine at the start of the program and call it again to return the speed to normal.

You might get a 2X + speed improvement for the 50g and bring it down to the 40 second neighborhood.

Yeah, but that would be cheating, wouldn't it. :) OTOH, a comparison of the C performance (a hpgcc-tigcc shootout) would be fair and should be interesting. Has anyone done that before?

Hi,

I'll run the C version on a HP49g+ tomorrow if someone wants. I think that even in the 12MHz power saving mode, the HP will still be much faster then a TI89. Before I proceed the program should print 875, correct?

Quote:
Before I proceed the program should print 875, correct?

Yes.

There's a slight mistake in Gileno's table: the running time for the HP-33S is actually 251 seconds. That's exactly one hundred times the Free42 time on the PalmTX: 2.51 seconds! (312 MHz ARM)

Gerson.


Edited: 3 Feb 2007, 12:37 p.m.

Correct !!! :-)

Oh, I dont' think it's cheating. If one can optimize the calculator to use integers to speed up a calculation, why can't you make the calculator run as fast as it is capable of running?

After all, you can have your 50g run at 150Mhz all the time with no ill effects, so why not a burst of speed to 203Mhz?

Back in the old TI-59 / HP41 contest days, the TI-59 fast mode was considered fair game to print calendars, factor integers, etc.

I vote it is fair! :-)

Obrigado, Gileno!

Mas por favor não se esqueça de corrigir também os tempos de Albert Graef (262 segundos para a HP-32S e 81 para a HP-50G).
Claro que Xerxes deve compilar sua própria tabela com suas próprias conclusões, mas a sua está +QD+!

Ah, anote mais um resultado: 806 seconds on the HP-42S (a meio caminho da sua HP-41CY e da PB-2000C de Marcus von Cube).

Até,

Gerson.

------------------


Thanks, Gileno!

Please don't forget to correct Albert Graef's results (262 seconds for the HP-32S and 82 seconds for the HP-50G). Of course Xerxes may compile his own table with his own conclusions, but your's is very good!

Take notice of yet another result: 806 seconds on the HP-42S (halfway between your HP-41CY and Marcus von Cube's PB-2000C)

Quote:
After all, you can have your 50g run at 150Mhz all the time with no ill effects

That's interesting. But I thought that there were display issues at that speed? And what about the clock?

Obrigado, Gerson!

Thanks, Gerson! :-)

#include <hpgcc49.h>

int main()
{
int x, y, r, s, t, a[9];
r = 8;
s = 0;
x = 1;
a[x] = r;
l0:if (x == r)
goto l4;
a[++x] = r;
l1:++s;
y = x;
l2:if (--y == 0)
goto l0;
if ((t = a[x] - a[y]) == 0)
goto l3;
if (x - y != abs(t))
goto l2;
l3:if (--a[x])
goto l1;
if (--x)
goto l3;
l4:sat_push_real(s);
beep(1);
return 1;
}

@12MHz

With the beep: ~.17 seconds . Remove the beep: ~.06s

Considering it takes around .05-.06 seconds to run an empty HPGCC program on the 50, you can easily see that it takes longer to START the program than to actually run it. Once HPGCC 3.0 comes out with integrated libraries, that launch time will be down to 12ms and we can start replacing rom routines left and right. . .

Ya'll may like the oldies. . . but I really like my new calc just fine. ;-)

TW

Shucks! Removed the nice formatted code. Oh well. :-(

TW

It isn't really the display that has issues so much, but rather the memory. The ram can only go up to around 120 on most units before delays start getting put in, so you loose any benefit. When it is going that fast the timing is all messed up and so the display/key polling won't work.

TW

Hi Tim,

Look like you beat me to the HPGCC version. Nice job 8)

Remember that the CPU has high speed cache so for small datasets overclocking should help a lot. Also there are a few kb of on-board RAM that doesn't require wait-states.

Hi Tim, thanks for clearing that up. Guess I'll stay away from overclocking then. The C figures are really impressive. Beats everything else hands down. I really like this calculator, and I'm looking forward to the hpgcc 3.0 release. :)

Albert

Quote:
Shucks! Removed the nice formatted code. Oh well. :-(

Try the "pre" tag the next time. :)

Properly formatted C code:

#include <hpgcc49.h>

int main()
{
int x, y, r, s, t, a[9];
r = 8;
s = 0;
x = 1;
a[x] = r;
l0:if (x == r) goto l4;
a[++x] = r;
l1:++s;
y = x;
l2:if (--y == 0) goto l0;
if ((t = a[x] - a[y]) == 0) goto l3;
if (x - y != abs(t)) goto l2;
l3:if (--a[x]) goto l1;
if (--x) goto l3;
l4:sat_push_real(s);
beep(1);
return 1;
}

But there is no reason to stay away from overclocking.

Especially if you have a program you'd like to accelerate. You can push the 50g to 203 Mhz at the start of a loop or other section that takes a while to run (like this example) and then put it back to normal.

Very easy to do.

Pull down the program here:

http://alpage.ath.cx/hptute/hpprog.htm

and read the text file included. It will give you info about when/how/why to do each different speed.

I do remember that there is a small high speed cache in there, but my point was to show that on such small tiny problems even at 12MHz it takes longer to start the program that to run it. If you have such a small dataset that it will fit entirely within the processor. . . I don't see how you could do enough with it to stress the ARM at all. Well, you could do a trillion multiplications or something, but anything useful I mean.

I have a program that parses a list of lists. These lists represent either line segments or curves on a road. With a list of lists with over 3000 segments (over 180 miles of road), you need to calculate position and offset to every segment, as well as the start and end points and location of every segment. Once you have done that, you can determine along which segment of road you are at.

Then you need to read in the elevation information for the road (either vertical curves or straight grades), and calculate the elevation at the current location. Then you look at a 2D cross section of the road at that position to find any change in elevation due to the offset from the center of the road.

At 75MHz, doing that process takes about .2 sec to spit back the coordinate and elevation--and my code isn't even really optimized yet! :-)

TW

I'm not familiar with the HP-50g. What is it doing that's so inefficient? To have a clock speed about 100 times that of the HP-71 and hardly be any faster-executing is ridiculous, especially if it does not have to handle everything as IEEE floating-point numbers like the 71 does.

This "benchmark" only involves integers, which most people on this forum are unwilling to work with for most applications, and which makes a huge performance difference on some machines but not all, meaning it's a rather worthless benchmark.

Edited: 4 Feb 2007, 8:18 p.m.

Quote:
Oh, I dont' think it's cheating. If one can optimize the calculator to use integers to speed up a calculation, why can't you make the calculator run as fast as it is capable of running?

After all, you can have your 50g run at 150Mhz all the time with no ill effects, so why not a burst of speed to 203Mhz?

Back in the old TI-59 / HP41 contest days, the TI-59 fast mode was considered fair game to print calendars, factor integers, etc.

I vote it is fair! :-)


I agree. Back in those days we understood that anything we could do which did not involve modifications of the hardware would be acceptable. There were always advocates on both sides who found that they could increase the speed of calculations by changing the clock rate. That was judged to be fair if and only if the manufacturer incorporated the hardware modification in his production line.

Quote:
Properly formatted C code:
[snip]

Ugh! Properly formatted Fortran more like. What's with all the line numbers?
;-)

Why don't you use a loop if the execution is too fast? Try the C version of this thread:

www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=107447#107447

:-)

I stopped since everything is being rewritten and is constantly changing. Once they give me the go-ahead, I will work more on it.

TW

Quote:
I'm not familiar with the HP-50g. What is it doing that's so inefficient?

The emulation layer?

Quote:
I'm not familiar with the HP-50g. What is it doing that's so inefficient?

As Gerson has already mentioned, emulation of the Saturn hardware is slow, even though it does fairly well considering that the 75MHz ARM isn't exactly the fastest cpu either, and that the Saturn is a completely different architecture. The RPL system with its included CAS is a lot more complex and powerful than any Basic interpreter (even the admittedly nice system on the 71B), so just reimplementing it from scratch on the new hardware without an emulation layer wasn't really practical. On the positive side this means that the 50g is still mostly compatible with previous RPL-based calculators even down to the Saturn assembler level.

Quote:
This "benchmark" only involves integers, which most people on this forum are unwilling to work with for most applications, and which makes a huge performance difference on some machines but not all, meaning it's a rather worthless benchmark.

No, the benchmark is not about arithmetic at all, but about the performance of program execution, which essentially means that it's about the implementation of the control structures. As I have already pointed out in another thread, combinatorial problems are as pure as it gets if you want to test this aspect of the programming facilities.

Of course, for the problem at hand you have to represent the board positions and deal with indices, that's where the numbers come in, but you'll find that in almost any non-trivial problem except pure numeric calculations. If you take a closer look at the variations of the program on different calculators, you'll notice that we just chose whatever numeric type was available for that purpose and was reasonably efficient. E.g., in my 50g benchmark I deliberately used floating point values instead of RPL integers (which can represent arbitrarily large integers and hence are much slower with arithmetic than floating point numbers).