Author Topic: HP Prime Relative Speed Testing- What is REALLY faster? (Read 13174 times)

iconmaster · « **on:** October 08, 2014, 05:30:45 pm »

As you guys may know, I'm working on an application that (in a way) optimizes HPPL code. So recently, I've been time-testing several methods of computation. So if you want to know absolutely what's faster to execute, you now have this thread!

I take 10,000 to 40,000 executions of a code snippet, and average the returned execution times. All parts of the programs being tested against each other have all other variables/code held constant. This isn't EXACTLY how long each operation takes; since there's boilerplate in there, too, all the times are relative. I did all of these on a physical calculator.

All units are in microseconds.

Now, on to the times!

PIECEWISE vs. IF...THEN...ELSE vs. IFTE

This was a test that looked like this:

Spoiler For Spoiler:

Code: [Select]

TEST1()
BEGIN
 X:=RANDINT(1,3);
 RETURN PIECEWISE(X==1,3,X==2,2,1);
END;

TEST2()
BEGIN
 X:=RANDINT(1,3);
 IF X==1 THEN
  RETURN 3;
 ELSE
  IF X==2 THEN
   RETURN 2;
  ELSE
   RETURN 1;
  END;
 END;
END;

TEST3()
BEGIN
 X:=RANDINT(1,3);
 RETURN IFTE(X==1,3,IFTE(X==2,2,3));
END;

So it tested an IF and a sub-IF.

The results are:

PIECEWISE	IF...THEN...ELSE	IFTE
115.3 μs	117.4 μs	115.2 μs

Conclusion: IFTE is very slightly faster here, but PIECEWISE might actually be better for larger chains of ELSEs. IF...END is right out.

PIECEWISE vs. IF...THEN...ELSE vs. IFTE... REDUX!

Let's test this thing against a version with no sub-case.

Spoiler For Spoiler:

Code: [Select]

TEST1()
BEGIN
 X:=RANDINT(1,2);
 RETURN PIECEWISE(X==1,3,4);
END;

TEST2()
BEGIN
 X:=RANDINT(1,2);
 IF X==1 THEN
  RETURN 3;
 ELSE
  RETURN 4;
 END;
END;

TEST3()
BEGIN
 X:=RANDINT(1,2);
 RETURN IFTE(X==1,3,4);
END;

The results are:

PIECEWISE	IF...THEN...ELSE	IFTE
100.6 μs	99.5 μs	98.5 μs

Conclusion: IFTE is the clear winner for simple IF cases.

MAKELIST vs. FOR

Let's execute a function. 1,000 times.

Spoiler For Spoiler:

Code: [Select]

FF(X)
BEGIN
 RETURN X;
END;

TEST1()
BEGIN
 MAKELIST(FF(I),I,1,1000);
END;

TEST2()
BEGIN
 FOR I FROM 1 TO 1000 DO
  FF(I);
 END;
END;

The results of this test are:

MAKELIST	FOR
12,900 μs	15,200 μs

Conclusion: MAKELIST is faster. Use it instead of for loops even if you throw away what it returns.

MAKELIST vs. FOR, Part 2

Let's make them go backwards.

Spoiler For Spoiler:

Code: [Select]

FF(X)
BEGIN
 RETURN X;
END;

TEST1()
BEGIN
 MAKELIST(FF(I),I,1000,1,-1);
END;

TEST2()
BEGIN
 FOR I FROM 1000 DOWNTO 1 DO
  FF(I);
 END;
END;

The results of this test are:

MAKELIST	FOR
14,200 μs	15,200 μs

Conclusion: MAKELIST takes a hit here, but is still better than FOR.

MAKELIST vs. FOR, Part 3

we had -1 as a step, so let's try 2.

Spoiler For Spoiler:

Code: [Select]

FF(X)
BEGIN
 RETURN X;
END;

TEST1()
BEGIN
 MAKELIST(FF(I),I,1,2000,2);
END;

TEST2()
BEGIN
 FOR I FROM 1 TO 2000 STEP 2 DO
  FF(I);
 END;
END;

The results of this test are:

MAKELIST	FOR
13,700 μs	15,200 μs

Conclusion: MAKELIST still wins. Also, the fact that FOR kept getting the same time each run is really creepy.

To get an int: From a string, list, or matrix?

What is the best way to store ints? Let's find out:

Spoiler For Spoiler:

Code: [Select]

SS:="1234567890";
TT:={48,49,50,51,52,53,54,55,56,57,58};
MM:=[[48,49,50,51,52,53,54,55,56,57,58]];

TEST1()
BEGIN
 RETURN SS[3];
END;

TEST2()
BEGIN
 RETURN TT[3];
END;

TEST3()
BEGIN
 RETURN MM[1,3];
END;

The results were:

STRING	LIST	MATRIX
54.0 μs	47.1 μs	63.0 μs

Conclusion: Strings, quite surprisingly, suck. Not so surprisingly, matrices are bad at storing 1D data.

Real 2D data - Lists of Matrices?

Well, what is a matrix good at? 2D data, right? Well, let's see:

Spoiler For Spoiler:

Code: [Select]

TT:={{1,2,3},{4,5,6}};
MM:=[[1,2,3],[4,5,6]];
TEST1()
BEGIN
 RETURN TT[1,2];
END;

TEST2()
BEGIN
 RETURN MM[1,2];
END;

The results were:

LIST	MATRIX
48.7 μs	53.3 μs

Conclusion: If you want speed, lists seem like the way to go.

3D data: Lists vs. complex arrays

Well, matrices can technically store 2 reals per slot: Complex arrays exist. So let's see if that's a good idea.

Spoiler For Spoiler:

Code: [Select]

TT:={{{1,1},{2,2}},{{3,3},{4,4}}};
MM:=[[(1,1),(2,2)],[(3,3),(4,4)]];
TEST1()
BEGIN
 RETURN TT[1,2,1];
END;

TEST2()
BEGIN
 RETURN IM(MM[1,2]);
END;

The results were:

LIST	MATRIX
50.3 μs	60.0 μs

Conclusion: Matrices are useless.

Well, unless you're doing math with them, I GUESS.

GETPIX vs. Lists

Maybe getting ints from a grob is faster than ints from a list. Or maybe even reals from a list!

Test 1 is GETPIX. Test 2 is getting a value from a 2d list of #ints. Test 3 is getting from a list of reals.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);
TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);

EXPORT TST()
BEGIN
 GETPIX_P(G1,10,10);
END;

EXPORT TST2()
BEGIN
 TT[10,10];
END;

EXPORT TST3()
BEGIN
 TTT[10,10];
END;

ONCOMPILE()
BEGIN
 DIMGROB_P(G1,100,100);
END;

lol_hax=ONCOMPILE();

Here are the results:

GETPIX	INTS[x,y]	REALS[x,y]
91.2 μs	82.8 μs	50.0 μs

Conclusion: GETPIX is slower than list access, at least for smallish indices. However, the main problem is probably the fact that you're getting back an integer, which is slow.

Big 1D Data

Let's compare strings to lists again. Let's bring this to THE MAX.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(49,X,1,10000);
TTT=ΣLIST(MAKELIST("1",X,1,10000));

EXPORT TST()
BEGIN
 TT[9999];
END;

EXPORT TST2()
BEGIN
 TTT[9999];
END;

The results are:

LIST[9999]	STRING[9999]
81.8 μs	88.4 μs

Conclusion: Lists still rule, but the divide IS closing ever so slightly.

2D data: Let's get big

The biggest power of 10 I can get for a list dimension is 100x100. Hmm.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(MAKELIST(Y,Y,1,100),X,1,100);
MM=MAKEMAT(I+J,100,100);

EXPORT TST()
BEGIN
 TT[99,99]
END;

EXPORT TST2()
BEGIN
 MM[99,99]
END;

EXPORT TST3()
BEGIN

END;

The results were:

LIST[99,99]	MAT[99,99]
82.2 μs	97 μs

Conclusion: Lists are still better. I'd test them out for more beefy values, but I can't. I run out of memory first!

Setting lists and strings

Well, I was just informed that you can put values IN strings. So let's test that out!

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(49,X,1,1000);
EXPORT TTT=ΣLIST(MAKELIST("1",X,1,1000));

EXPORT TST()
BEGIN
 TT[999]:=5326;
END;

EXPORT TST2()
BEGIN
 TTT[999]:=5326;
END;

The results were:

LIST[999]	STRING[999]
613.0 μs	112.6 μs

Conclusion: Setting values is much, much slower than getting them. Here, strings serve as an EXTREMELY good storage mechanism. So strings are better if you're willing to have a longer access time.

Making large strings

How does one make a large string programmatically? Well, there's the built in ΣLIST function that works, but what else can work? CHAR could do.

The strings are 100 characters long.

Spoiler For Spoiler:

Code: [Select]

EXPORT TST()
BEGIN
 ΣLIST(MAKELIST("1",X,1,100));
END;

EXPORT TST2()
BEGIN
 CHAR(MAKELIST(49,X,1,100));
END;

The results are:

ΣLIST	CHAR
2,153 μs	561 μs

Conclusion: CHAR is by far better here. It's a good thing CHAR works on lists!

Even More Iteration Code

ITERATE is a function that exists. It's hard to make it work like MAKELIST, but sometimes you don't need it to work like MAKELIST

.

Spoiler For Spoiler:

Code: [Select]

FF()
BEGIN

END;

EXPORT TST()
BEGIN
 MAKELIST(FF(),X,1,1000);
END;

EXPORT TST2()
BEGIN
 ITERATE(FF(),X,1,1000);
END;

EXPORT TST3()
BEGIN
 FOR I FROM 1 TO 1000 DO
  FF();
 END;
END;

The results are as follows:

MAKELIST	ITERATE	FOR
10,500 μs	7,900 μs	18,900 μs

Conclusion: If you don't care too much about the iteration count, ITERATE is better. I would bet it to be superior even if you put code in FF to make ITERATE give you back a real iteration value.

... Do I bet?

I'm feeling lucky.

Spoiler For Spoiler:

Code: [Select]

FF(X)
BEGIN
 RETURN X+1;
END;

EXPORT TST()
BEGIN
 MAKELIST(FF(X),X,1,1000);
END;

EXPORT TST2()
BEGIN
 ITERATE(FF(X),X,1,1000);
END;

EXPORT TST3()
BEGIN
 FOR I FROM 1 TO 1000 DO
  FF(I);
 END;
END;

The results are:

MAKELIST	ITERATE	FOR
35,700 μs	39,300 μs	48,200 μs

Conclusion: Passing a parameter costs you a lot of time.

Oh, and I guess I lost that bet.

Fun fact with lists: Use LIST[0] to get the last element of a list. Set something to LIST[0] to append it to the end of the list. This is a sensible way to do things. Yessir.

Well, that's really all the useful ones I have right now. I'll do more later. Feel free to ask me for more comparisons!

DJ Omnimaga · « **Reply #1 on:** October 08, 2014, 05:54:56 pm »

(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished.

)

Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<

Also, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.

iconmaster · « **Reply #2 on:** October 08, 2014, 09:35:25 pm »

Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm

(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<

Yeah, I know what you mean. Looking back at HP Tetris, I realize that representing the grid with a complex matrix was a bad idea.

Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm

Also, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.

Do you mean testing list access vs. pixel access? If that's what you mean, sure! Im going to guess that lists are faster, but who knows! This is why I'm testing.

bb010g · « **Reply #3 on:** October 08, 2014, 10:05:18 pm »

I must say I'm surprised on MAKELIST & IFTE being fastest. Could you try a 3 conditional PIECEWISE vs. IFTE test? Also, you forgot 1D ([1,2,3]) vectors. (Although you can't nest those outside of CAS.)

DJ Omnimaga · « **Reply #4 on:** October 08, 2014, 10:24:25 pm »

Quote from: iconmaster on October 08, 2014, 09:35:25 pm

Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<

Yeah, I know what you mean. Looking back at HP Tetris, I realize that representing the grid with a complex matrix was a bad idea.

Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm
Also, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.

Do you mean testing list access vs. pixel access? If that's what you mean, sure! Im going to guess that lists are faster, but who knows! This is why I'm testing.

Yeah that's what I mean. Some TI-84+ programmers use pictures to store map data, but on the HP Prime it's even more convenient in the way that pixel-test can actually detect which color the pixel is, while on the color 84+ it only detects if the pixel is transparent or not.

bb010g · « **Reply #5 on:** October 08, 2014, 10:26:01 pm »

Quote from: DJ Omnimaga on October 08, 2014, 10:24:25 pm

Quote from: iconmaster on October 08, 2014, 09:35:25 pm
Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<

Yeah, I know what you mean. Looking back at HP Tetris, I realize that representing the grid with a complex matrix was a bad idea.

Quote from: DJ Omnimaga on October 08, 2014, 05:54:56 pm
Also, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.

Do you mean testing list access vs. pixel access? If that's what you mean, sure! Im going to guess that lists are faster, but who knows! This is why I'm testing.
Yeah that's what I mean. Some TI-84+ programmers use pictures to store map data, but on the HP Prime it's even more convenient in the way that pixel-test can actually detect which color the pixel is, while on the color 84+ it only detects if the pixel is transparent or not.

Don't forget the memory allocation is more generous for GROBs.

DJ Omnimaga · « **Reply #6 on:** October 08, 2014, 10:29:25 pm »

What do you mean? Are lists and matrices limited to a max amount of elements (eg on the 84+ it was 999 and on the 82 it was 99) or do you refer to how much larger GROB data is?

bb010g · « **Reply #7 on:** October 08, 2014, 10:31:06 pm »

Quote from: DJ Omnimaga on October 08, 2014, 10:29:25 pm

What do you mean? Are lists and matrices limited to a max amount of elements (eg on the 84+ it was 999 and on the 82 it was 99) or do you refer to how much larger GROB data is?

I'm not sure about list size limitations, but IIRC Tim said that they treated GROBs more favourably memory-wise.

DJ Omnimaga · « **Reply #8 on:** October 08, 2014, 10:37:57 pm »

Ah ok. IIRC list limitations were removed or increased in the 2nd firmware. At first there were leftover limits from the HP 39gII and people complained. However, I wouldn't take large GROB capacity for granted. When I run multiple games that involves usage of GROB then attempt running a particularly complex program such as Cute Invaders or my pseudo 3D thing, large chunks of graphics fail to be displayed or are truncated (in the case of Cute Invaders, some frames are missing, resulting into extreme sprite flicker). I suspect it's a memory leak issue caused by firmware bugs. Basically, pre-rendering an entire 256x48 tilemap made of 16x16 tiles into a very large 4096x768 GROB then attempting to display a 320x240 chunk of it at once is not recommended (at least for the time being), not that it's very memory-efficient anyway.

timwessman · « **Reply #9 on:** October 09, 2014, 12:16:54 am »

I think your matrix/list results will change dramatically if you have much larger lists and matrices.

The reason why is that a matrix has a single type and constant sizing of each object. It can encode things in a much more efficient way since you do not have an identifier for each number. In a list, each number will be much larger since the type of the object much be encoded as well as the size to the next object.

In short, a matrix should be much faster once you have more then a very small number of objects to jump over since it is a direct index due to all objects being known. It will also be much smaller then an equally sized list.

A string should also overtake a list for much the same reason. The comment in the release notes about "string"[n] avoiding memory copy was because previously you had to call a function to get a specific character ( MID("ABCDE",3,1) vs "ABCDE"[3] IIRC). Thus your string would get copied unnecessarily.

I am not surprise about the IFTE and MAKELIST being the fastest.

iconmaster · « **Reply #10 on:** October 09, 2014, 06:13:39 pm »

Okay, here's more speed tests! I'll put the more relevant ones in the OP.

GETPIX vs. Lists

Maybe getting ints from a grob is faster than ints from a list. Or maybe even reals from a list!

Test 1 is GETPIX. Test 2 is getting a value from a 2d list of #ints. Test 3 is getting from a list of reals.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);
TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);


EXPORT TST()
BEGIN
 GETPIX_P(G1,10,10);
END;


EXPORT TST2()
BEGIN
 TT[10,10];
END;


EXPORT TST3()
BEGIN
 TTT[10,10];
END;


ONCOMPILE()
BEGIN
 DIMGROB_P(G1,100,100);
END;


lol_hax=ONCOMPILE();

Here are the results:

GETPIX	INTS[x,y]	REALS[x,y]
91.2 μs	82.8 μs	50.0 μs

Conclusion: GETPIX is slower than list access, at least for smallish indices. However, the main problem is probably the fact that you're getting back an integer, which is slow.

Big 1D Data

Let's compare strings to lists again. Let's bring this to THE MAX.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(49,X,1,10000);
TTT=ΣLIST(MAKELIST("1",X,1,10000));

EXPORT TST()
BEGIN
 TT[9999];
END;

EXPORT TST2()
BEGIN
 TTT[9999];
END;

The results are:

LIST[9999]	STRING[9999]
81.8 μs	88.4 μs

Conclusion: Lists still rule, but the divide IS closing ever so slightly.

2D data: Let's get big

The biggest power of 10 I can get for a list dimension is 100x100. Hmm.

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(MAKELIST(Y,Y,1,100),X,1,100);
MM=MAKEMAT(I+J,100,100);


EXPORT TST()
BEGIN
 TT[99,99]
END;


EXPORT TST2()
BEGIN
 MM[99,99]
END;


EXPORT TST3()
BEGIN


END;

The results were:

LIST[99,99]	MAT[99,99]
82.2 μs	97 μs

Conclusion: Lists are still better. I'd test them out for more beefy values, but I can't. I run out of memory first!

Setting lists and strings

Well, I was just informed that you can put values IN strings. So let's test that out!

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(49,X,1,1000);
EXPORT TTT=ΣLIST(MAKELIST("1",X,1,1000));

EXPORT TST()
BEGIN
 TT[999]:=5326;
END;

EXPORT TST2()
BEGIN
 TTT[999]:=5326;
END;

The results were:

LIST[999]	STRING[999]
613.0 μs	112.6 μs

Conclusion: Setting values is much, much slower than getting them. Here, strings serve as an EXTREMELY good storage mechanism. So strings are better if you're willing to have a longer access time.

Making large strings

How does one make a large string programmatically? Well, there's the built in ΣLIST function that works, but what else can work? CHAR could do.

The strings are 100 characters long.

Spoiler For Spoiler:

Code: [Select]

EXPORT TST()
BEGIN
 ΣLIST(MAKELIST("1",X,1,100));
END;

EXPORT TST2()
BEGIN
 CHAR(MAKELIST(49,X,1,100));
END;

The results are:

ΣLIST	CHAR
2,153 μs	561 μs

Conclusion: CHAR is by far better here. It's a good thing CHAR works on lists!

Even More Iteration Code

ITERATE is a function that exists. It's hard to make it work like MAKELIST, but sometimes you don't need it to work like MAKELIST

.

Spoiler For Spoiler:

Code: [Select]

FF()
BEGIN

END;

EXPORT TST()
BEGIN
 MAKELIST(FF(),X,1,1000);
END;

EXPORT TST2()
BEGIN
 ITERATE(FF(),X,1,1000);
END;

EXPORT TST3()
BEGIN
 FOR I FROM 1 TO 1000 DO
  FF();
 END;
END;

The results are as follows:

MAKELIST	ITERATE	FOR
10,500 μs	7,900 μs	18,900 μs

Conclusion: If you don't care too much about the iteration count, ITERATE is better. I would bet it to be superior even if you put code in FF to make ITERATE give you back a real iteration value.

... Do I bet?

I'm feeling lucky.

Spoiler For Spoiler:

Code: [Select]

FF(X)
BEGIN
 RETURN X+1;
END;

EXPORT TST()
BEGIN
 MAKELIST(FF(X),X,1,1000);
END;

EXPORT TST2()
BEGIN
 ITERATE(FF(X),X,1,1000);
END;

EXPORT TST3()
BEGIN
 FOR I FROM 1 TO 1000 DO
  FF(I);
 END;
END;

The results are:

MAKELIST	ITERATE	FOR
35,700 μs	39,300 μs	48,200 μs

Conclusion: Passing a parameter costs you a lot of time.

Oh, and I guess I lost that bet.

DJ Omnimaga · « **Reply #11 on:** October 09, 2014, 11:52:38 pm »

Thanks for the new tests. Also, Getpix is not too bad it seems. The much easier map editing will be worth the speed loss I guess.

iconmaster · « **Reply #12 on:** October 10, 2014, 09:42:29 pm »

Thinking about GETPIX again, I was wondering about SETTING data. So here is:

PIXON vs. List Set

Spoiler For Spoiler:

Code: [Select]

TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);
TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);

EXPORT TST()
BEGIN
 PIXON_P(G1,50,50,#0);
END;

EXPORT TST2()
BEGIN
 TT[50,50]:=#0;
END;

EXPORT TST3()
BEGIN
 TTT[50,50]:=0;
END;

ONCOMPILE()
BEGIN
 DIMGROB_P(G1,100,100);
END;

lol_hax=ONCOMPILE;

The results were:

PIXON_P	INTS	REALS
74 μs	4,144 μs	3,616 μs

Conclusion: PIXON is impossibly fast. So fast, in fact, that I'm wondering if I messed up my time test somewhere. Of course, even if pixels are really fast, you have to worry about working with ints, which are noticeably slower than reals. If those results are real, though, I might have to suggest working with grobs myself.

DJ Omnimaga · « **Reply #13 on:** October 10, 2014, 11:41:07 pm »

On the other hand, if you try to store a picture-based map data with DIMGROB, then the result is atrociously large, since each pixel is like 64 bytes or so in unicode form (maybe more?). Size-wise, every other alternative is more viable, but again this calc has a lot of memory so that is not a big issue.

iconmaster · « **Reply #14 on:** October 11, 2014, 04:49:38 pm »

Quote from: DJ Omnimaga on October 10, 2014, 11:41:07 pm

On the other hand, if you try to store a picture-based map data with DIMGROB, then the result is atrociously large, since each pixel is like 64 bytes or so in unicode form (maybe more?). Size-wise, every other alternative is more viable, but again this calc has a lot of memory so that is not a big issue.

This is why you use ICON, IIRC. It's better than DIMGROB, even if not by much. You can edit the contents of an ICON, just not change its size. You can even pass around the string that represents the ICON if you need to.

Author Topic: HP Prime Relative Speed Testing- What is REALLY faster? (Read 13174 times)

iconmaster

HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

iconmaster

Re: HP Prime Relative Speed Testing- What is REALLY faster?

bb010g

Re: HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

bb010g

Re: HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

bb010g

Re: HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

timwessman

Re: HP Prime Relative Speed Testing- What is REALLY faster?

iconmaster

Re: HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

iconmaster

Re: HP Prime Relative Speed Testing- What is REALLY faster?

DJ Omnimaga

Re: HP Prime Relative Speed Testing- What is REALLY faster?

iconmaster

Re: HP Prime Relative Speed Testing- What is REALLY faster?