FreeBasic's Timer

[hhr]

You should test the functions with a suitable graphics program.
Name me a program that might be suitable for testing and I will try to test it.

[deltarho[1859]]

On my PC, I never see any noticeable "flickering" whatever the configuration.

Neither do I.

I thought fxm's CPU load of 23% was high when I was getting 15%. hhr's 50% with regulate(60,32) and the fact he is still using Win7 tells me that his machine is probably getting a bit 'long in the tooth'.

You may be surprised to learn that Timer is so fine-grained, we go through the Timer pooling loop millions of times. It occurred to me that it may be beneficial to include a negative counter within the Timer pooling loop and only test the Timer after the count became zero. I played around with various count values, allowing a reduced accuracy but still acceptable. We don't really need the accuracy we are getting.

However, whatever gain I got on reducing the CPU load, I lost almost the very same amount by including a counter. So, it was a case of one step forward and one step back.

At the end of the day, the only way to get a substantial reduction in CPU load is to have a more powerful CPU. Games enthusiasts overclock their CPUs to the point of nearly frying them not for the fun of it, but because they want the greatest GHz they can get.

[deltarho[1859]]

@hhr

You wrote: “You shouldn't argue.” I agree, but dodicat wrote: “If you have a hero then good and well. Myself, I have very few heroes, and I like it that way.” He wasn't talking about Father Christmas. He then praised fxm on a damage limitation exercise. I cannot put up with that.

[deltarho[1859]]

Just for the record, this is what I got.

Code: Select all

Press ENTER to stop monitoring PID #6640
         CPU Load:  3.15
         Max Load:  3.94
         95% Conf Interval:  3.54 ± 0.84
         Session Time:  67.0 seconds
 
    Press ENTER to stop monitoring PID #5232
         CPU Load:  3.30
         Max Load:  4.28
         95% Conf Interval:  3.75 ± 0.49
         Session Time:  73.0 seconds

Testing a lot of delay(10) with a threshold of 3ms.

The second test used a counter. As you can see, using a counter was not beneficial.

The app I used was my CPULoad2 which monitors the load of individual processes and is more informative than Task Manager.

Added: With no _setTimer and 32ms I got:

Code: Select all

95% Conf Interval:  10.79 ± 8.25

[fxm]

My own results for 'mouse and maze':
(viewtopic.php?p=298935#p298935)

Code: Select all

CPU Usage 'mouse and maze' (I added my 'framerate()' result)

Without "timeBeginPeriod":
sleep regulate(60,fps),1:  0% and FPS a little less stable  '' default configuration
regulate(60,32)         : 21% and FPS stable
regulate(60, 3)         :  0% and FPS a little slower (50) but stable
regulate(60, 0)         :  0% and FPS slower (30) but stable

With "timeBeginPeriod":
sleep regulate(60,fps),1:  0% and FPS stable
regulate(60,32)         : 21% and FPS very stable
regulate(60, 3)         :  4% and FPS very stable  '' default configuration
regulate(60, 0)         :  1% and FPS very stable

[dodicat]

Thanks fxm.
Looks good.

"You can fool some of the people all of the time, and all of the people some of the time, but you can not fool all of the people all of the time." Possibly Abraham Lincoln.

dodicat I have just put you on my ignore list.

What the heck are you on about deltarho.
We had agreed to stop all this bickering.
I really think you are missing MrSwiss now.
If it's about fxm (I think), I regard fxm as a developer of freebasic.
Each new edition has his artifacts and ideas built in, I use the help files when needed, which he builds.
We have the occasional spat, but I regard that as healthy.
I have never contributed to the development of fb, nor intend to.
I find the odd bug and express opinions sometimes.
Regarding fxm's regulator, my only crib is running timebegin period automatically (in an official .bi file), such a powerful windows function should be started at the coder's discretion, and not behind the scenes.

[neil]

@fxm
I am using Linux.
I get these 2 errors when I compile with #include "delay_regulate_framerate.bi"
delay_regulate_framerate.bi(11) error 9: Expected expression in '#elseif __FB_LINUX__'
delay_regulate_framerate.bi(21) error 9: Expected expression in '#elseif __FB_LINUX__'

[fxm]

@Jeff,

Can you tell me if the code below is safe (to change the default value of a procedure parameter during the program execution) ?
For my part, I would think it is !

Code: Select all

Sub test(Byval I As Integer) : Print I : End Sub
    
#undef test
Declare Sub test(Byval I As Integer = 1)
test()

#undef test
Declare Sub test(Byval I As Integer = 2)
test()

#undef test
Declare Sub test(Byval I As Integer = 3)
test()

Sleep

Because I would prefer for the Windows users to be able to switch between basic resolution and high resolution for the OS cycle period, by just calling a macro (either '_HighResolutionOS()' or '_BasicResolutionOS()').

This thanks to modified declarations in the 'delay_regulate_framerate.bi' file header as follows:

Code: Select all

#ifdef __FB_WIN32__
    Declare Function _setTimer Lib "winmm" Alias "timeBeginPeriod"(ByVal As Ulong = 1) As Long
    Declare Function _resetTimer Lib "winmm" Alias "timeEndPeriod"(ByVal As Ulong = 1) As Long
    #macro _HighResolutionOS()
        #undef delay
        #undef regulate
        Declare Sub delay(ByVal amount As Single, ByVal threshold As Ulong = 2 * 1)
        Declare Function regulate(ByVal MyFps As Ulong, ByVal threshold As Ulong = 2 * 1) As Double
        _setTimer()
    #endmacro
    #macro _BasicResolutionOS()
        #undef delay
        #undef regulate
        Declare Sub delay(ByVal amount As Single, ByVal threshold As Ulong = 2 * 16)
        Declare Function regulate(ByVal MyFps As Ulong, ByVal threshold As Ulong = 2 * 16) As Double
        _resetTimer()
    #endmacro
    _HighResolutionOS()
#elseif __FB_LINUX__
    Declare Sub delay(ByVal amount As Single, ByVal threshold As Ulong = 2 * 10)
    Declare Function regulate(ByVal MyFps As Ulong, ByVal threshold As Ulong = 2 * 10) As Double
#elseif __FB_DOS__
    Declare Sub delay(ByVal amount As Single, ByVal threshold As Ulong = 2 * 55)
    Declare Function regulate(ByVal MyFps As Ulong, ByVal threshold As Ulong = 2 * 55) As Double
#else
    Declare Sub delay(ByVal amount As Single, ByVal threshold As Ulong = 2 * 16)
    Declare Function regulate(ByVal MyFps As Ulong, ByVal threshold As Ulong = 2 * 16) As Double
#endif

Declare Function framerate() As Ulong

On the other hand, such a macro could only be used at the global scope level because it contains declarations for compilation. Not possible either to fully skip it using a Goto (declaration line also can not be skipped by a Goto).
The new declarations are only taken into account for the following lines of code explicitly calling 'delay()' or 'regulate()'.

[deltarho[1859]]

'[rant]
When writing code, we need to be careful of what I call user-friendly creep.

Many years ago, when I first got into cryptography, I wrote a cryptographic application which had more user options than we can shake a stick at.

I read a blog by the cryptographer Bruce Schneier. He took the view that too many options with cryptographic software was bad.

I went back to my application and ripped out many options. If, for example, option A was better than option B, for example, why was I giving option B? So, I removed option B and hard-wired option A.

When I finished, the resulting application was much better. There were still some options left, but they were easy to understand and did not require expert knowledge in choosing which to use. Schneier was absolutely right.

So, it is with fxm's delay() and regulate(). A user wants to #include his code and then get cracking on writing their latest masterpiece. They would rather not spend time going through the #include to decide which path to take.

I am all for user-friendly code, but we should not overdo it otherwise, guess what, it becomes less user-friendly.
'[/rant]

[fxm]

In the file to include, the high resolution for Windows is automatically forced.
The user will find out that there is an option to revert to the basic resolution for Windows only by reading the very last paragraph of the documentation page.

[deltarho[1859]]

@fxm

OK, I will buy that. It does not invalidate my rant, which should be borne in mind when investigating further 'improvements'.

[coderJeff]

@Jeff,

Can you tell me if the code below is safe (to change the default value of a procedure parameter during the program execution) ?

Safe in the sense that we should expect the compiler to be predictable and produce deterministic code; if not then is probably a bug in the compiler

Unsafe in the sense that assumes this is a decision that can be solved at compile time in user code.

Unsafe in the sense that it assumes user will know about or understand any use of delay() will depend on:
- macro definition versus invocation (location in program)
- function pointer initialization versus invocation
- single module versus multi module compilation

[deltarho[1859]]

Following hhr's research, I used my CPULoad2 to compare fxm's regulate and dodicats's regulate.

My CPULoad2 gives the current target's load, the maximum load during a session, and a confidence limit of the load. The confidence limit requires a sufficient number of samples to allow a statistical analysis, before which we just get the average so far displayed. I wrote CPULoad2 six years ago and had forgotten how useful it is. Task Manager gives the current target's load and a graphical representation of the load on the CPU covering all processes. CPULoad2 is then more informative of a single process. It has several command line switches, one of which I don't understand what it's for. I can remember conversations I had 50 years ago but struggle to remember the ins and outs of code written only six years ago. With old age, short-term memory becomes unreliable and there is very little that we can do about it.

hhr wrote: "For CPU Usage, Dodicat's feature is the winner."

My research is confirming this. dodicat's CPU usage is negligible.

hhr also wrote: “You should test the functions with a suitable graphics program. Name me a program that might be suitable for testing and I will try to test it.”

Time does not permit me to do much work on this, and I invite hhr to return to this. To save time searching for CPULoad2 and reading a long thread, I am happy to give hhr CPULoad2's source code; which is small and a 32-bit binary of only 109 KiB.

[deltarho[1859]]

It has several command line switches, one of which I don't understand what it's for.

I do now.

Going through the code, I felt that it was above my pay grade – but I wrote it. I do not like getting old.

[fxm]

@Jeff,

Can you tell me if the code below is safe (to change the default value of a procedure parameter during the program execution) ?

Safe in the sense that we should expect the compiler to be predictable and produce deterministic code; if not then is probably a bug in the compiler

Unsafe in the sense that assumes this is a decision that can be solved at compile time in user code.

Unsafe in the sense that it assumes user will know about or understand any use of delay() will depend on:
- macro definition versus invocation (location in program)
- function pointer initialization versus invocation
- single module versus multi module compilation

Alright, I drop that idea.