Calculator Community > HP Calculators
HP Prime Relative Speed Testing- What is REALLY faster?
iconmaster:
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: ---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();
--- End code ---
Here are the results:
GETPIXINTS[x,y]REALS[x,y]91.2 μs82.8 μs50.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: ---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;
--- End code ---
The results are:
LIST[9999]STRING[9999]81.8 μs88.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: ---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;
--- End code ---
The results were:
LIST[99,99]MAT[99,99]82.2 μs97 μ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: ---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;
--- End code ---
The results were:
LIST[999]STRING[999]613.0 μs112.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: ---EXPORT TST()
BEGIN
ΣLIST(MAKELIST("1",X,1,100));
END;
EXPORT TST2()
BEGIN
CHAR(MAKELIST(49,X,1,100));
END;
--- End code ---
The results are:
ΣLISTCHAR2,153 μs561 μ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: ---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;
--- End code ---
The results are as follows:
MAKELISTITERATEFOR10,500 μs7,900 μs18,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: ---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;
--- End code ---
The results are:
MAKELISTITERATEFOR35,700 μs39,300 μs48,200 μs
Conclusion: Passing a parameter costs you a lot of time.
Oh, and I guess I lost that bet.
DJ Omnimaga:
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:
Thinking about GETPIX again, I was wondering about SETTING data. So here is:
PIXON vs. List Set
Spoiler For Spoiler:
--- Code: ---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;
--- End code ---
The results were:
PIXON_PINTSREALS74 μs4,144 μs3,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:
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:
--- 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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version