Author Topic: Bad random numbers, or TIMER limitation...?  (Read 6204 times)

0 Members and 1 Guest are viewing this topic.

Offline Statsman1

  • Newbie
  • Posts: 36
  • I'm just a jerk, but a hero is what I want to be.
    • View Profile
Re: Bad random numbers, or TIMER limitation...?
« Reply #30 on: October 26, 2021, 09:24:51 pm »
@Richard ...

Thank you very much for the code.  I modified it to behave somewhat in the way I am trying to do my thing...

Code: QB64: [Select]
  1. version$ = "Precision_timer-999"
  2. Declare Dynamic Library "kernel32" ' Acquiring high-resolution time stamps  ' https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
  3.     Sub QueryPerformanceCounter (ByVal lpPerformanceCount As _Unsigned _Offset)
  4.     Sub QueryPerformanceFrequency (ByVal lpFrequency As _Unsigned _Offset)
  5. Dim Shared PerformanceCount As _Integer64
  6. Dim Shared StartingCount As _Integer64
  7. Dim Shared dElapsedTime As Double
  8. Dim Shared dElapsedTimeOLD As Double
  9.  
  10. For reps = 1 To 20
  11.     QueryPerformanceFrequency (_Offset(Frequency))
  12.     QueryPerformanceCounter (_Offset(StartingCount))
  13.  
  14.     TIMERe: dElapsedTimeOLD = dElapsedTime
  15.  
  16.     dist = 1440
  17.     draws = 0
  18.     Do
  19.  
  20.         steps = Int(Rnd(1) * 3) + 1
  21.         dist = dist - steps
  22.         draws = draws + 1
  23.  
  24.     Loop Until dist < 0
  25.  
  26.     TIMERe
  27.  
  28.     Print "Time to take 1440 steps =";: Print Using "####.###"; (dElapsedTime - dElapsedTimeOLD) * 1000000;: Print "    Loops =";: Print draws
  29.  
  30. Next reps
  31.  
  32.  
  33. Sub TIMERe
  34.     QueryPerformanceCounter (_Offset(PerformanceCount))
  35.     dElapsedTime = (CDbl(PerformanceCount - StartingCount)) / Frequency

...and attached the results in the first attachment.  I then did the same for 14,400 steps, if you will, and the results are in the second attachment.

Those outliers that you talk about - I guess that can be lived with, as that would impact every horse in a race, not just one.  I am encouraged by the results of the second run - the more loops, the more varied the times seem to be, even for the same number of loops to complete the test.
Good decisions come from experience.
Experience comes from bad decisions.

Offline Richard

  • Seasoned Forum Regular
  • Posts: 364
    • View Profile
Re: Bad random numbers, or TIMER limitation...?
« Reply #31 on: October 26, 2021, 10:16:42 pm »
@Statsman1

Thanks for letting me know about your success with the program.

Just for your info, the two lines immediately following the FOR reps  =  1 to 20 statement can be moved to just outside the loop (i.e. place line before FOR...)

The "frequency" relates to a conversion factor to convert (eventually) computer crystal cycles to 1 second counts - as it is highly unlikely that you would change the clock speed of the computer (or that the processor + hardware is even capable to achieve this on "older computers") - it only needs to be "determined once" (I think the value for all MS compatible computers is 1000000 (or 10000000) - it is actually not determined by windows in any manner I think).

The "StartingCount" I believe relates to clock counts (as 100 nano-second counts) since the computer was restarted (or is it since JAN 1 1972 or something)? In either case for your computer session (i.e. since you did a restart) - likewise it only has to be established once per run.

In fact because you are measuring a time interval of an event (race time) - you are only working with the DIFFERENCE (from start to finish) - so the subtraction of StartingCount (in both TIMERe instances cancel out mathematically). Similarly with Frequency (which can  be taken as being CONSTANT) - that too can be taken out (i.e. program calculate using number of 100 nanosecond counts (= Performance count) and when you finally report (print/display the results then divide Difference in PerformanceCounts by 10000000 to convert to seconds. You may gain a timing improvement of 1 to 10 nanoseconds!. :)

As far as the outliers go - and I am still trying to find a work-around to the problem - in my case (referring to reply # 180 mentioned above) - the outlier WAS usually NOT the first timing in any of my loops (which had a number of code line between timing points) - which is a "killer" in trying to determine which code module was "faster".

So if the outlier occurred within your group of events (rather than start) - it might have the effect (say) of a horse "jumping the rails" to take a short cut to the finish line (or to go back to the starting gate). :)
« Last Edit: October 26, 2021, 10:28:25 pm by Richard »