Hi,
I noticed that pressing the keys slows down the program execution even if there is no check if any key was pressed.
Here is a simple example of drawing a color table and taking a time measurement of this drawing.
You need real hardware to perform this test.
I tried this on newest FW 2.0.0.13865 (2018 07 06).
Code:
EXPORT PERF_TEST()
BEGIN
local tck,x,y;
RECT_P(G0,#0); //clear screen
REPEAT
TICKS▶tck;
//draw color table
FOR x FROM 1 TO 38 DO
FOR y FROM 1 TO 27 DO
RECT_P(x*8,y*8,x*8+6,y*8+6,RGB(x*6,y*7,(x+y)*3));
END;
END;
//get the time measurnment
TICKS-tck▶tck;
TEXTOUT_P(tck,G0,5,230,1,#FFFFFF,100,#0); //show the time
UNTIL 0;
END;
My Prime shows about 260ms measurement in no key is pressed and about 330ms when pressed. Pressing the key slows down the program execution by 25% in this case. That's quite a lot of time considering the fact that the program does not even have a test for pressing a key.
What is the reason?
(08-05-2018 02:06 PM)komame Wrote: [ -> ]Hi,
I noticed that pressing the keys slows down the program execution even if there is no check if any key was pressed.
Here is a simple example of drawing a color table and taking a time measurement of this drawing.
You need real hardware to perform this test.
I tried this on newest FW 2.0.0.13865 (2018 07 06).
Code:
EXPORT PERF_TEST()
BEGIN
local tck,x,y;
RECT_P(G0,#0); //clear screen
REPEAT
TICKS▶tck;
//draw color table
FOR x FROM 1 TO 38 DO
FOR y FROM 1 TO 27 DO
RECT_P(x*8,y*8,x*8+6,y*8+6,RGB(x*6,y*7,(x+y)*3));
END;
END;
//get the time measurnment
TICKS-tck▶tck;
TEXTOUT_P(tck,G0,5,230,1,#FFFFFF,100,#0); //show the time
UNTIL 0;
END;
My Prime shows about 260ms measurement in no key is pressed and about 330ms when pressed. Pressing the key slows down the program execution by 25% in this case. That's quite a lot of time considering the fact that the program does not even have a test for pressing a key.
What is the reason?
Bonjour
Peut-être le fait qu'un programme peut être stoppé
avec la touche 'ON' et qu'il y a un test en ce sens lorsque une touche
est enclenchée.
Seulement un hypothèse.
Hello
Maybe the fact that a program can be stopped
with the key 'ON' and that there is a test in this sense when a key
is engaged.
Only a hypothesis.
(08-05-2018 03:31 PM)Tyann Wrote: [ -> ]Maybe the fact that a program can be stopped
with the key 'ON' and that there is a test in this sense when a key
is engaged.
Only a hypothesis.
If it works the way you wrote, the ON-key test is always performed because even if key is not pressed the test has to be checked. But when the result of the test is 'false' (other key is pressed) it shouldn't be so much affecting the time of program execution.
The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change. From memory, the keyboard driver spawns some threads, triggers some interrupts and runs on timers. Its a really poor design and implementation. Pressing a key triggers all sorts of behavior in the background that interrupts the main application thread and chews up time.
Tim,
I just downgraded the FW to 10077 and now the program works faster (230ms while not pressing a key and 285ms while pressing).
Regardless of how internal OS keyboard handlers were written, you can see that in FW 10077, the programs were executed faster.
I also wrote about it in this thread about my game two years ago after upgrading to FW 10637, when I noticed a significant decrease in performance compared to FW 10077.
http://www.hpmuseum.org/forum/thread-4841.html
In FW 10637 were problems with the flow of animation during the key pressing that did not occurs in version 10077.
I think that there is still the possibility of improving something and speeding up the execution of programs (even while the keys are not pressed) since in earlier FW they were executed faster.
(08-06-2018 01:09 AM)Tim Wessman Wrote: [ -> ]The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change.
Why would HP use an OS over which they have no control? Seems risky to me.
(08-06-2018 05:00 PM)toml_12953 Wrote: [ -> ] (08-06-2018 01:09 AM)Tim Wessman Wrote: [ -> ]The slowdown isn't on the calculator code side due to any checking, but rather some poorly written OS behaviors and drivers that we don't have any ability to change.
Why would HP use an OS over which they have no control? Seems risky to me.
Probably for the same reasons that most software developers use an OS, RTOS, TCP stack, memory manager, device driver or other software modules that were written by others on most moderate to complex projects. To save time and money in not having to write code for a task that has already been written and debugged. The tradeoff is that you often do not have control over how that code operates or any idiosyncrasies it may have. Even open source code may be difficult to modify depending on how it was written. In many cases you may have to accept the limitations of code written by others or perform workarounds to achieve the functionality/reliability you want. The other tradeoffs are the potential cost of licensing the software module/OS (which can be substantial) and the potential complexity of integrating it into your project.
Hello,
"Why would HP use an OS over which they have no control? Seems risky to me."
As you know, the Prime is manufactured by a 3rd party company called Besta.
Besta is more known for a then typical asian products "digital dictionaries/translators". And this is where Prime HW and OS originated.
What we did was put HP "calcualtor" application on top of a modified Besta dictionary and OS.
Doing so saves a lot of time as you reuse existing/working HW and SW.
So, here is the answer to the why.
Cyrille