Can HP Prime be faster? - firmware performance comparison

[komame]

Jeff,

Thank you for showing interest in this topic. It makes me feel that the time I dedicated to it is not in vain and provides some hope that someone will address this issue.

Quote:The change in the framebuffer format should be visible in the emulator. Today I tried (a portion of) your PPL program on revisions 14730 and 11226 of the emulator (on Windows, in both cases). I’m attaching two screenshots; upon close inspection, banding should be seen on the screen capture from the revision 11226 emulator.

Reading your answer, I realized that my description was not entirely clear, in fact it was even wrong. When conducting my tests, I did not use an emulator and everything was performed on a real HP Prime device. I didn't install emulators with older firmware versions, as it wasn't necessary for my purposes. However, the screenshots I took for documenting results came from the "Monitor" tool available within the HP Connectivity Kit, where I could view the device's screen on my PC via USB connection. In this regard, regardless of the firmware version (12066/13333), the image displayed was the same. However, I must clarify that this is not an emulator but rather the HP Connectivity Kit's "Monitor" feature. I sincerely apologize for my imprecise words.

Quote:The framebuffer format change doesn’t substantially increase rendering code complexity (it may even, arguably, simplify some parts), but it does result in more memory being moved around by the parts of the project involved with graphics. (Including, for example, refreshing.)

All that said, your numbers show efficiency changing both before and after the change in framebuffer formats.

You're correct, transitioning from a 16-bit mode to a 32-bit mode should indeed simplify the code. This stems from the fact that the 16-bit mode (e.g., 565 mode) requires a number of bit-level operations (shifts, bitwise AND/OR) to enable a single pixel, whereas the 32-bit mode allows manipulation of whole bytes with straightforward assignment operations (simplistically speaking), without bit-level manipulation (I've written a set of graphics commands directly in ARM assembly code that draw lines, ellipses, bitmaps in 565 mode, so I'm familiar with this).

Returning to the topic of performance, after further analysis, I now believe that this change positively impacted performance. Let's reconsider the excerpt of the graph where the 32-bit mode was introduced.
   
All three data series experienced a sudden drop (a global influence affected all three processes). However, it's evident that the yellow series dropped half as much as the other two series. While iterating an empty loop and simple numeric calculations dropped by about 13% in percentage terms, pixel activation dropped only by 7%. Had this global factor not contributed to the drop, we might have observed a 6-7% increase in pixel activation performance.

I'm genuinely pleased to hear about plans for performance improvements, and I'm hopeful that with the next, or perhaps subsequent, firmware versions, we'll notice some positive changes in this regard.

Thanks!