newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(09-06-2018 12:34 AM)acoto Wrote:  Hello Claudio -

https://newrpl.wiki.hpgcc3.org/doku.php?...essorspeed

Question: how expensive in term of CPU cycles is the CPU speed change, and the program monitoring to trigger a speed change?

There's no "program" monitoring the speed, simply a timer that runs out in 500 ms (or 300ms, can't recall exactly). When newRPL is waiting idle for a key to be pressed, it simply keeps resetting the timer, and slowing down the clock if needed.
When you run a program, the timer isn't reset and ends up expiring, triggering a hardware interrupt that changes the clock to the maximum speed.
So there's a little overhead in the clock switch, and the only other overhead is when the CPU is idle, not when it's busy.

(09-06-2018 12:34 AM)acoto Wrote:  I think it may be interesting to always speed up when starting a calculation, no matter if simple or complex, calculator may feel faster, and always return to low speed when finish and returning to UI.

The calculator UI feels pretty quick as it is. Most simple calculations are instantaneous, and speeding up the clock makes them feel instantaneous just the same, but burning more battery.
The idea with the clock switch is that only when a computation is taking long enough to be annoying to the user we'll run at full power. The 300 ms (or 500ms) feels fine. Perhaps we can have a user setting to tune that timer from 50ms to 500 ms, so the user can control how "responsive" their calculator feels.

(09-06-2018 12:34 AM)acoto Wrote:  Then as newRPL evolves, it may be interesting to run different applications at different speeds, for instance a Equation writer may requite higher base speed than UI or than a Matrix Writer.

Nothing that's UI related should require the faster clock. Besides, the UI is subject to the same timer so if anything takes more than 300 ms the faster clock will kick in just as it does when you run a program.