HP Prime speed vs TI-Nspire CX

[falcon56215]

I was wondering how raw execution performance varies between these two calculators.

I wrote a basic loop and executed it on the Prime...

EXPORT TEST()
BEGIN
FOR I FROM 1 TO 1000000 STEP 1 DO END;
PRINT("DONE.");
END;

To count up from 1 to a million took the Prime about 11.5 seconds.

Can anyone who has an Nspire perform the same test and see how long it takes? If you have a Prime, do you get similar results to mine? Does performance vary much from calculator to calculator? Just curious...

[roadrunner]

Define test()
Prgm
For I,1,10000

EndFor
Disp "done"
EndPrgm

takes about 11 seconds. I didn't want to wait for a million iterations, or even 100,000 for that matter.

This is with the handheld, the emulator would be much faster.

-road

[falcon56215]

Wow. Is that using the built in programming language? I wonder how it would fair if someone coded it using C or ASM, compiled it, and ran it under ndless... or are we comparing apples to oranges?

[roadrunner]

That was ti-basic on a ti nspire cx cas. You can program the cx's in Lua, that may speed thing up a bit. Lua programming requires the emulator, which I don't have handy at the moment.

If you did code that program in assembly for the ti, I'd still bet on the prime to beat it though.

-road

[Carlos295pz]

[Disp "done"] should not be within For?

Define test()
Prgm
For I,1,10000
Disp "done"
EndFor
EndPrgm

[falcon56215]

You could do that, but it would slow the loop down considerably, as well as displaying 1,000,000 / 10,000 "done" messages on the screen! The way it is written, it just displays done to let you know the loop has finished processing. You might have missed the closing END at the end of the Prime's FOR loop... it is at the end of the statement. The last END in the prime program pairs with the BEGIN statement, so done is printed after the loop finishes executing in the Prime program as well.

[toml_12953]

(11-07-2016 12:08 PM)falcon56215 Wrote:  I was wondering how raw execution performance varies between these two calculators.

I wrote a basic loop and executed it on the Prime...

EXPORT TEST()
BEGIN
FOR I FROM 1 TO 1000000 STEP 1 DO END;
PRINT("DONE.");
END;

To count up from 1 to a million took the Prime about 11.5 seconds.

Can anyone who has an Nspire perform the same test and see how long it takes? If you have a Prime, do you get similar results to mine? Does performance vary much from calculator to calculator? Just curious...

My Prime did it in 11.38 sec (timed using TEVAL). I did take out the step value, however. It's not needed when the step is 1.

Tom L

[falcon56215]

Cool. I am new to the Prime, the TEVAL function is quite handy. Running 5 tests gives me

11.349 seconds
11.479 seconds
11.346 seconds
11.384 seconds

So.. some variance between runs but not much. It seems to be really fast for a BASIC language. Most BASIC languages I have seen are interpreted and compiled at run time, which makes them really slow, but it looks like the Prime pre-compiles the code when you run CHECK or exit the editor? Regardless, it seems to be a really nice piece of tech for hashing out some quick programs. I think I am going to enjoy having it around.

[toml_12953]

(11-08-2016 02:48 PM)falcon56215 Wrote:  Cool. I am new to the Prime, the TEVAL function is quite handy. Running 5 tests gives me

11.349 seconds
11.479 seconds
11.346 seconds
11.384 seconds

So.. some variance between runs but not much. It seems to be really fast for a BASIC language. Most BASIC languages I have seen are interpreted and compiled at run time, which makes them really slow, but it looks like the Prime pre-compiles the code when you run CHECK or exit the editor? Regardless, it seems to be a really nice piece of tech for hashing out some quick programs. I think I am going to enjoy having it around.

I think you'll enjoy it, too. I'm a big fan of PPL (Prime Programming Language). At one point I was going to develop a standard BASIC interpreter for the Prime but PPL has everything I need and I've found that porting most BASIC programs to it is very easy so there's little need for a BASIC interpreter. The Prime blows away all the other calculators I've tried in benchmarks. If it had an SD card slot and printing capability, I would rarely ever use a computer! As impressive as CAS is, I don't use it at all and wish HP would make a separate calculator for it rather than the mish-mosh we have now where even experienced uses can get hung up with variable names, function names and the way functions are evaluated. (JMTC!)

Tom L
Tom L

[StephenG1CMZ]

(11-08-2016 03:42 PM)toml_12953 Wrote:  

(11-08-2016 02:48 PM)falcon56215 Wrote:  Cool. I am new to the Prime, the TEVAL function is quite handy. Running 5 tests gives me

11.349 seconds
11.479 seconds
11.346 seconds
11.384 seconds

So.. some variance between runs but not much. It seems to be really fast for a BASIC language. Most BASIC languages I have seen are interpreted and compiled at run time, which makes them really slow, but it looks like the Prime pre-compiles the code when you run CHECK or exit the editor? Regardless, it seems to be a really nice piece of tech for hashing out some quick programs. I think I am going to enjoy having it around.

I think you'll enjoy it, too. I'm a big fan of PPL (Prime Programming Language). At one point I was going to develop a standard BASIC interpreter for the Prime but PPL has everything I need and I've found that porting most BASIC programs to it is very easy so there's little need for a BASIC interpreter. The Prime blows away all the other calculators I've tried in benchmarks. If it had an SD card slot and printing capability, I would rarely ever use a computer! As impressive as CAS is, I don't use it at all and wish HP would make a separate calculator for it rather than the mish-mosh we have now where even experienced uses can get hung up with variable names, function names and the way functions are evaluated. (JMTC!)

Tom L
Tom L

The one thing that PPL lacks wrt BASIC is a GOTO statement, which would really help to make sense of some old listings. Though I recall reading of a workaround, having it built-in would occasionally be useful.

[jte]

(11-08-2016 05:57 PM)StephenG1CMZ Wrote:  …The one thing that PPL lacks wrt BASIC is a GOTO statement…

This is sorta funny in that Cyrille unabashedly uses goto in the Prime source code. You don't need to convince him of its utility! Cyrille has posted about the difficulties in implementing goto in PPL.

[toml_12953]

(11-08-2016 05:57 PM)StephenG1CMZ Wrote:  

(11-08-2016 03:42 PM)toml_12953 Wrote:  I think you'll enjoy it, too. I'm a big fan of PPL (Prime Programming Language). At one point I was going to develop a standard BASIC interpreter for the Prime but PPL has everything I need and I've found that porting most BASIC programs to it is very easy so there's little need for a BASIC interpreter. The Prime blows away all the other calculators I've tried in benchmarks. If it had an SD card slot and printing capability, I would rarely ever use a computer! As impressive as CAS is, I don't use it at all and wish HP would make a separate calculator for it rather than the mish-mosh we have now where even experienced uses can get hung up with variable names, function names and the way functions are evaluated. (JMTC!)

Tom L

The one thing that PPL lacks wrt BASIC is a GOTO statement, which would really help to make sense of some old listings. Though I recall reading of a workaround, having it built-in would occasionally be useful.

I'd like to know what the workaround is! I have some very unstructured BASIC programs that defy my attempts to structure them.

Tom L

[toml_12953]

(11-08-2016 06:43 PM)jte Wrote:  

(11-08-2016 05:57 PM)StephenG1CMZ Wrote:  …The one thing that PPL lacks wrt BASIC is a GOTO statement…

This is sorta funny in that Cyrille unabashedly uses goto in the Prime source code. You don't need to convince him of its utility! Cyrille has posted about the difficulties in implementing goto in PPL.

Even C and Pascal have a GOTO statement. How hard could it be to implement it? Even though there's no explicit GOTO, any of the looping constructs must allow an internal GOTO in order to repeat the same block of code. Even if GOTO wasn't allowed to branch out of a block such as FOR or REPEAT, it could still be useful.

Tom L

[falcon56215]

I don't know about that. Although there have been times where a GOTO statement would have proved useful, I have found other ways to implement those tasks such as WHILE 1=1 DO... I always thought GOTO statements make a program very hard to debug, as you can literally jump to anywhere from anywhere at anytime. Following execution of the program then becomes a nightmare... at least with loops and functions there is some hint of order. (Don't get me started on recursive functions though....) I think with enough thoughtful planning you would not need GOTO statements.

[Adriweb]

FWIW, on my TI-Nspire CX CAS, the following Lua code takes 2.28s ("2280ms" is displayed) :

Code:

local start = timer.getMilliSecCounter()
for i=0,1000000 do end
local msg = timer.getMilliSecCounter()-start

function on.paint(gc)
    gc:drawString(msg .. "ms", 0, 0)
end

The Nspire Basic is slow, as everyone knows, but Lua is pretty decent. Too bad TI didn't embed LuaJIT... that would have been quite the awesomeness.

[toml_12953]

(11-08-2016 08:18 PM)falcon56215 Wrote:  I don't know about that. Although there have been times where a GOTO statement would have proved useful, I have found other ways to implement those tasks such as WHILE 1=1 DO... I always thought GOTO statements make a program very hard to debug, as you can literally jump to anywhere from anywhere at anytime. Following execution of the program then becomes a nightmare... at least with loops and functions there is some hint of order. (Don't get me started on recursive functions though....) I think with enough thoughtful planning you would not need GOTO statements.

True. For new programs, GOTO may be unnecessary but when converting hundreds of old BASIC programs, it sure would come in handy!

Tom L

[DGM]

(11-08-2016 08:59 PM)toml_12953 Wrote:  True. For new programs, GOTO may be unnecessary but when converting hundreds of old BASIC programs, it sure would come in handy!

Tom L

In one of my programming classes (possibly dating back to the early 70's, so it might have been FORTRAN), we used to say "A bad design deserves a redesign". Don't convert --- rewrite! Another book I read indicated that you should write your program, get it debugged and running perfectly, then throw it away and write it again from scratch based on what you learned.

We had a lot of fun those days writing 10 lines of code a day.

David M

[debrouxl]

The Prime has a 400 MHz ARM9 CPU, while the Nspire CX (CAS) 's ARM9 CPU is clocked at 132 (HW < W) or 156 (HW >= W) MHz by the OS (depending on the hardware version) and can be overclocked through Ndless to 198-270 MHz (average in the low 200s, significant standard deviation).
A Prime-based implementation of Lua would handsomely beat the Nspire

[StephenG1CMZ]

(11-08-2016 07:54 PM)toml_12953 Wrote:  

(11-08-2016 05:57 PM)StephenG1CMZ Wrote:  The one thing that PPL lacks wrt BASIC is a GOTO statement, which would really help to make sense of some old listings. Though I recall reading of a workaround, having it built-in would occasionally be useful.

I'd like to know what the workaround is! I have some very unstructured BASIC programs that defy my attempts to structure them.

Tom L

I think this was the thread I was thinking of as a workaround for goto...
On my list of things I need to try out.
http://www.hpmuseum.org/forum/thread-521...light=goto

[cyrille de brébisson]

Hello,

1) "…The one thing that PPL lacks wrt BASIC is a GOTO statement…"
2) "How hard can it be"
3) "Goto do exist in the background to do loops"
4) "This is sorta funny in that Cyrille unabashedly uses goto in his code. You don't need to convince him of its utility!"

GOTO is all about context. If a GOTO crosses "control blocks" and "local variable start/end of existance", then GOTO are VERY hard to implement because you need first detect which boundaries are crossed and artificially exit/enter these control blocks and kill/create the local variables out of the normal process. This "rebukes" 2 and explains 3.

About 4. Yes, I do use goto (any good programmer will, every once in a while, because it makes sense).
BUT, 90% of my goto use is to exit multiple loops at once, which you can not do in C (or other programming languages)... HOWEVER, you CAN do it in PPL using the BREAK(n) and CONTINUE(n) function!!!! As far as I know, PPL is the ONLY language that has such constructs!!!
I also use it to deal with exceptional cases (errors) with a goto error; with error: at the bottom of the function so that all the cleanup code for the function and the return of an error can be handled in the same place. This is not as needed in PPL as objects and memory is cleared/freed by the system...

So, yes, I do use GOTO and no PPL does not offer a GOTO, but this should not be seen as the "pot calling the kettle black" as I did everything that I could to make GOTO as unnecessary as possible in PPL.

Enjoy your programs!
Cyrille