+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: program execution speed as library vs variable HP50G (/thread-9196.html)
program execution speed as library vs variable HP50G - snrowe - 09-30-2017 02:50 AM
Hi,
I've been working on porting a program that I wrote for the HP48SX to the other 48/49/50G calculators and noticed some strange behavior running the program as a library from the non hp48SX calculator models.
The main issue is when the program is run as a library on the G series calcs execution time slows down drastically opposed to running the program as a variable or as a library on the 48SX. I tracked down the slowdown of the program to the execution of the 'MEM' command. I tried using the SYSRPL version of the command that doesn't force GC and the program ran at normal speed but the memory reported was no longer accurate. I find it odd that the program runs at normal speed when the variable form of the program is executed, but has trouble being run as a library.
Can anyone shed light on what might be causing this? Any work around for executing MEM from a library program without a major slowdown?
Any insight on to what causes this would be greatly appreciated.
Thanks,
Scott
RE: program execution speed as library vs variable HP50G - cyrille de brébisson - 10-02-2017 05:48 AM
Hello,
When running as a library, in which port is your library stored?
Also remember that the G series have more RAM than the S series, thus the GC is slower...
Cyrille
RE: program execution speed as library vs variable HP50G - DavidM - 10-02-2017 05:15 PM
(09-30-2017 02:50 AM)snrowe Wrote: I've been working on porting a program that I wrote for the HP48SX to the other 48/49/50G calculators and noticed some strange behavior running the program as a library from the non hp48SX calculator models.
...
If you're calling subroutines from your library within inner loops of routines, the overhead of loading the subroutine code from a port can also slow things down noticeably (something I'm dealing with right now in the ListExt library).
The way I'm addressing this (so far) is to "pre-fetch" the subroutine code at the beginning of a given library command, store it in a local (which keeps it in TEMP), then run the local version of the subroutine within the loop as needed. This has improved the performance of the affected commands, even when stored in port 0.
The amount of impact depends on how often the subroutines are called, of course.
Just something to consider!
RE: program execution speed as library vs variable HP50G - snrowe - 10-03-2017 01:05 AM
(10-02-2017 05:48 AM)cyrille de brébisson Wrote: Hello,
When running as a library, in which port is your library stored?
Also remember that the G series have more RAM than the S series, thus the GC is slower...
Cyrille
It was in port 3 on card 2. I just confirmed that it runs at normal speed from port 1 and 0 so it must be GC run from a covered port is much slower than a non covered port.
I had a loop that was displaying the time and free mem every loop, I could see the clock tick every second when running from the uncovered port and every ~5 seconds from the covered port.
Don't have my hp50G and 49G with me now but I'll try all the ports with those as well later this week.
Thanks for pointing me in the right direction.
Scott
RE: program execution speed as library vs variable HP50G - snrowe - 10-03-2017 01:50 AM
(10-02-2017 05:15 PM)DavidM Wrote: If you're calling subroutines from your library within inner loops of routines, the overhead of loading the subroutine code from a port can also slow things down noticeably (something I'm dealing with right now in the ListExt library).
The way I'm addressing this (so far) is to "pre-fetch" the subroutine code at the beginning of a given library command, store it in a local (which keeps it in TEMP), then run the local version of the subroutine within the loop as needed. This has improved the performance of the affected commands, even when stored in port 0.
The amount of impact depends on how often the subroutines are called, of course.
Just something to consider!
Thanks for the information. There are many sub routines in this library (165) and some of the larger parts of the program have a number of nested loops. The program in question has a structure like shown below.
«
LOCAL VARS...
«
DO CLLCD DEPTH 'd' STO
IFERR STUFF...
DO -1 TICKS J T
«
DO 'J' INCR @<-- DavidM From your recommendation years ago to prioritize key presses once a key has been pressed.
IF THEN
STUFF...
DATE TIME TSTR " MEM:" MEM + + N SDISP
STUFF...
END
UNTIL KEY
END
»
UNTIL 0
END
THEN DEPTH d - DROPN
ask user to Exit?
END
UNTIL Exit?
END
»
»
RE: program execution speed as library vs variable HP50G - DavidM - 10-03-2017 03:16 AM
(10-03-2017 01:50 AM)snrowe Wrote: There are many sub routines in this library (165) and some of the larger parts of the program have a number of nested loops. The program in question has a structure like shown below. ...
165 subroutines? Looks like you've grown this app suite quite a bit over the years!
I know you're already aware of the exploded list element issue -- have you been able to rule that out as the cause for the slowdowns?
RE: program execution speed as library vs variable HP50G - cyrille de brébisson - 10-03-2017 04:44 AM
Hello,
If your lib is not in port 0 or 1, then each object of the lib needs to be copied from the card to RAM when they are called because the card emmory is not direcctly addressable (it is hidden behind the other card). This takes a lot of time, AND memory which is then GC'ed by the system.
This is the cause of your slow down.
You can circumvent this by loading all the most used functions in ram and storing them in local variables, and then call the local variables instead of your lib xobjs... This will be much faster. However, more memory is consumed as the objects will stay in RAM for the duration of the program.
Cyrille
RE: program execution speed as library vs variable HP50G - Software49g - 10-03-2017 10:22 AM
Hello,
another way would be to uncover the memory bank in question, run your code there directly and then cover the memory bank.
This is a little slower than using unnamed LAMs for you routines but it does not consume any extra memory in TempOb.
However, there a couple of pitfalls (for the 50g). If you uncover a bank than it is strictly forbidden to call a FLASHPTR directly as it will crash your machine. However, it is possible (depending on the code that the FLASHPTR calls) to run some short FLASHPTR routines from TempOb by putting the FLASHPTR into a secondary, copy it to TempOb and run it from there.
It does require some overhead at the beginning but it significantly speeds up your routine, especially if your routine calls a lot of subroutines as the memory bank is uncovered.
Access is as fast, as if your library would be stored in Port0!
And yet another approach for only one routine:
Copy it at the beginning of TempOb (bottom of TEMPOB) where normally the VirtualStack resides. Then call your routine directly via ML calls – no overhead at all but you must ensure that your routine is there and valid when you call it because the O.S. might overwrite it.
Both ways are used extensively in the message library and in GUISLV/GUIMES and they significantly speed up execution.
HTH,
Andreas