Can HP Prime be faster? - firmware performance comparison

[jte]

Piotr,

As someone who’s flashed HP Primes more than a few times, I can certainly appreciate the hours needed to be spent doing all this testing. Thank you for your efforts, and for sharing them with us.

I read over your post a few times and started writing a reply last night, but wanted to run one test because of the following:

(08-27-2023 09:52 AM)komame Wrote:  ⋮
During the tests, I also noticed a change in pixel filling between firmware versions 12066 and 13333:

You should know that this is not visible in the emulator; the effect can only be observed on a real HP Prime. I had to take photos of the screens to show you this comparison.

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.

Quote:The difference in rendering color shade thresholds for individual values is clearly visible. In version 13333, they are very smooth. If this had an impact on performance, I think it would be beneficial if the programmer had the option to choose the rendering mode.
⋮

While I was sleeping, Tim was posting This shows the power of Tim! (And of time zones?) Just like for Tim, the framebuffer format change also immediately popped up in my mind. The change in the framebuffer format is a low-level change. (The low-level graphics routines were adjusted / rewritten.) Revision 13333 was the first public release with the new framebuffer format. 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.

One task I was hoping to get done this summer was setting up an automated system for running tests on physical HP Primes. (Initially for integration into the bug tracker I set up, but also to verify / produce reports on how code changes affect efficiency. For this latter use case, I was thinking more along the lines of: this part of the code is going to get changed, so (A) log some performance data, (B) make changes, and (C) log some performance data [and, perhaps, GOTO (B)]. But, clearly, monitoring for performance changes in a more general manner would be wise. I should note that completing automated testing is part of getting a release out. [My intent is to increase the amount of automation.])

I’ve a variety of performance improvements I’ve been meaning to get to implementing — on the parts of the system I implemented in the past (which, incidentally, don’t overlap with the parts of the system you’ve been testing…).

There’s certainly much more that can be said on the topic of efficiency improvements. Benchmarks suites that reflect real-world use cases (along with automated testing) can certainly help guide development. For the moment, though, to ensure this reply gets posted, I’ll stop here for the moment.

Thanks again!

Jeff

Revision 11226 emulator:
   

Revision 14730 emulator: