Calculator Community > HP Calculators

HP Prime Relative Speed Testing- What is REALLY faster?

<< < (2/4) > >>

bb010g:

--- 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. :trollface:)


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 >.<

--- End quote ---

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. :P


--- 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.

--- End quote ---

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.

--- End quote ---
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.

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

DJ Omnimaga:
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:

--- 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?

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

DJ Omnimaga:
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:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page