RAM to ROM

[Cold Calculator]

I just got the HP Prime G2. I’m noticing problems with memory in the PPL programming language. I don’t much about hardware, but it looks like a RAM to ROM issue. What I'm trying to do is record the 3D animation of a simulation. I stored the vertices of each polygon to a list accessible outside the program. My problem is that as a list grows larger the simulation will slow down. I can exit out of the program then load again. The performance is still bad but what is interesting is that if I hit the pinhole reset on the back I will get the blazing speed that I love and the list of all the polygon data will still be there (sometimes but not always). My guess is when I hit the reset button my list went from RAM to ROM, freeing up RAM to do calculations. So my question is how do I transfer a list from RAM to ROM without doing reset? Thank you.

[glfiedler]

I do not have an answer to your speed issue but RAM TO ROM is not what is happening. ROM is "Read Only Memory". You cannot push data to a ROM.

[Raymond Del Tondo]

(09-27-2024 08:46 PM)Cold Calculator Wrote:  So my question is how do I transfer a list from RAM to ROM without doing reset?

Not at all. You can create backups to Flash, which can be seen as pseudo-ROM depending on the perspective, but it isn't really ROM.

If your calc slows down during program run, then it could be proportional to the amount of data to be managed.
Each data element to be added to the list will produce a new list in RAM,
and propably still reserve room for the old list.
So if there are thousands of elements, the amount of RAM used for new incarnations of the list will grow with big steps.
This and the needed garbage collections will take time, and thus slow down the machine.

But it could also mean that there are too many pending returns from recursions.

While recursions can be elegant from a mathematican's view,
you could try to flatten program run, by trying to eliminate some return levels.
I did this at least once in the past in a program for the HP 48, and it worked well.

There may be other causes, but those mentionned above came into my mind first.

[nbc12]

It really depends on how you are using the list. If you are iterating over the list element by element anywhere in your program and not solely pushing elements onto the back, it would make sense that the program would slow down as the list size grows, the processor just has to do more work for each subsequent element that you compute.

Moving data from ram to rom, to me, sounds like a bandaid solution to make it faster anyway, to say nothing about the feasibility of it. IMO the real solution is investigating if you can optimize your algorithm. Assuming it is at least O(n) time complexity of course, I can't see your code. The prime may be the fastest calculator, but every processor struggles with nested loops over large lists. If you have just two nested loops, as list size grows linearly compute time could grow quadratically. It can make a huge difference to simplify things like that, if you can.

There is a small chance the slowness is an issue caused by the PPL compiler, but I doubt it. You could try porting your code to Python to see if PPL is the problem. Micropython is faster than PPL anyway, plus it's mostly portable to regular CPython. Just a thought.

[Cold Calculator]

Thanks for the thoughts, guys. After a week of driving myself crazy, I found a workaround. Store data to a [vector] instead of to a {list}. I don't know why lists are slower, but that the way it is. In future iterations of Prime, I think they should do away with PPL and just go with Python.