Varying speed of a program.
|
05-21-2022, 09:46 AM
(This post was last modified: 05-21-2022 11:49 AM by matalog.)
Post: #1
|
|||
|
|||
Varying speed of a program.
I have been trying to measure how long a program takes to run using TICK:
Code: T1:=TICKS Which seems to do what it says it will. The problem is that it is different every time I run the program it returns a different length. There is no random WAIT() or anything that I would have thought would vary the runtime of the program. Any Ideas what causes the program runtime to change? To give an idea, it has been varying between 51 and 42 seconds for one program, and between 55 and 50 seconds for another. It seems to run fastest when the calculator has just been turned on. |
|||
05-21-2022, 10:02 AM
Post: #2
|
|||
|
|||
RE: Varying speed of a program.
Bonjour,
On va éventuellement confirmer ou infirmer, mais je pense aux possibilités suivantes : - soit à problème de gestion de mémoire en lien avec les applications ou autre. - soit à un vidage de la mémoire qui n'intervient pas quand il faudrait ou en tout cas aléatoirement en apparence. (05-21-2022 09:46 AM)matalog Wrote: I have been trying to measure how long a program takes to run using TICK: |
|||
05-21-2022, 05:01 PM
(This post was last modified: 05-21-2022 11:45 PM by matalog.)
Post: #3
|
|||
|
|||
RE: Varying speed of a program.
Running this program 4 times, I get 4 different runtimes, increasing from time of startup. 187,288, 190,297 and 199,373 200,310.
Code: EXPORT SPTEST() Are you saying that this is a known problem, and someone is looking into it? |
|||
05-21-2022, 10:09 PM
Post: #4
|
|||
|
|||
RE: Varying speed of a program.
(05-21-2022 10:02 AM)albud44 Wrote: Bonjour, Gene as Moderator: English only please in the forums. No one here will mind if the english used is not 100% British or American. I assure you no one wants to see my French or Latin! Google translate on the above: ---------------------------- Hello, We will eventually confirm or deny, but I am thinking of the following possibilities: - either a memory management problem related to applications or other. - either to a dumping of the memory which does not intervene when it should or in any case randomly in appearance. |
|||
05-21-2022, 11:47 PM
(This post was last modified: 05-21-2022 11:48 PM by matalog.)
Post: #5
|
|||
|
|||
RE: Varying speed of a program.
I'm not sure if that reply means that it is a known issue.
Can anyone run that program I listed in the second last post a couple of times and see if they also experience the difference in runtimes? I have not experienced programming languages that have different run-times in the same programs! It may be a useful way to generate random numbers along the way, through sub-programs being run :-). |
|||
05-22-2022, 01:34 AM
(This post was last modified: 05-22-2022 01:38 AM by anyfoo.)
Post: #6
|
|||
|
|||
RE: Varying speed of a program.
(05-21-2022 11:47 PM)matalog Wrote: I have not experienced programming languages that have different run-times in the same programs! Oh, but there are plenty which do just by themselves. Anything with a JIT (the more dynamic the worse) or with a garbage collector, unless the start conditions are exactly the same. Even if they are or even if your language is entirely deterministic (say it's compiled C), modern operating systems will switch the core away from the current thread to whatever else needs running, and that is not deterministic. And even if that is not the case, interrupts and varying times to handle them still aren't deterministic and effectively introduce some "jitter". And a modern general purpose CPU will have caches and instruction pipelines that add onto that. If you wanted to benchmark something on a C64 in the 80s, you already better took the average of multiple runs. Try on anything modern that isn't a simple microcontroller, and you have to make a lot of runs just to "warm up" the system to fill its caches and so on. (There are "real time" operating systems, but those mostly just give upper bound guarantees, not full determinism.) The question is how significant the differences are, and whether it makes sense given e.g. the system's time slices for threads. If you change your program to calculate, say, 5 times as much, does the absolute jitter stay the same or does it seem to scale with the amount of calculation it has to perform? |
|||
05-22-2022, 09:26 AM
Post: #7
|
|||
|
|||
RE: Varying speed of a program.
(05-21-2022 11:47 PM)matalog Wrote: I'm not sure if that reply means that it is a known issue. 25,085 -106 -101 -143 -238 -543 -114 -114 -150 -143 All on iPad, the four last it was laying still on a table, the earlier ones I was holding the tablet and moving a bit. |
|||
05-23-2022, 10:55 AM
Post: #8
|
|||
|
|||
RE: Varying speed of a program.
I noticed that sometimes after running my program Supersonic Ball a few times for a while that the game will slow down occasionally during execution, especially when exiting with the ON key. Rebooting fixes it.
-Dream of Omnimaga https://dreamofomnimaga.page |
|||
05-24-2022, 08:43 PM
Post: #9
|
|||
|
|||
RE: Varying speed of a program.
(05-22-2022 01:34 AM)anyfoo Wrote:(05-21-2022 11:47 PM)matalog Wrote: I have not experienced programming languages that have different run-times in the same programs! The jitter seems to scale with the program. I ran this program twice. It takes 5 hours on an emulator, so I didn't want to run it again (it is a quine of sorts btw): Code: EXPORT TfsUPs() And it took, 1st try: 19,391,369 ticks then 2nd try: 19,530,835. |
|||
05-25-2022, 03:51 PM
(This post was last modified: 05-25-2022 04:09 PM by Albert Chan.)
Post: #10
|
|||
|
|||
RE: Varying speed of a program.
To speed up, we could do in-place divide, instead of building up quotient, 1 char at a time.
This eliminated cost of generating intermediate strings, and cost of garbage collection, both O(n^2) (Timing jitters likely comes from unpredictable timing of garbage collection.) With positive integer divisor, dividend has enough room to hold the quotient. CAS> s := "12345" CAS> s[1] =< "0" // in-place string update CAS> s → "02345" s is treated just like an array, with INPUT showed array_sto("0",s[1]) Instead of removing quotient leading zeroes, we could track index of first non-zero entry. Comment: we might as well work with true array, saving cost of str/num conversions. HOME> L1 := ASC("12345") - 48 → {1,2,3,4,5} HOME> L1[1] := 0 → {0,2,3,4,5} |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 3 Guest(s)