An accurate form of Sleep()?

Code:

---

bool Thread::Sleep(unsigned long dwMilli) throw()
        {
            unsigned long long qwCurrent(0),qwPrevious(0),qwDifference(0),qwTicksPast(0);
            const unsigned long long nFrequency = GetTicksInSecond(); // Uses QueryPerformanceFrequency
            const unsigned long long nTicksInMilli = nFrequency / 1000;
            const unsigned long long nMilliTicks = nTicksInMilli * dwMilli;

            qwCurrent = GetCurrentTicks(); // Uses QueryPerformanceCounter

            do
            {
                qwPrevious = qwCurrent;
                qwCurrent = GetCurrentTicks();

                qwDifference = qwCurrent - qwPrevious;

                qwTicksPast += qwDifference;

                if (qwTicksPast >= nMilliTicks)
                {
                    break;
                }
            } while (true);
        }

---

Seems pretty accurate to me.

What exactly is your point with this thread? Do you have problem?

I don't think this is an 'accurate' form of Sleep(). When the code encounters a Slepp() call, the thread gives up its time slice back to the task scheduler. When it is its time slice again, it checks if it is the time for Sleep() to end and continue execution, if it is isn't, the thread will give up its time slice again, and so on. Sleep() doesn't hog the CPU with this endless loop, afaik.

I decided to check. The results are attached to this post.

Interesting to note... Kind of proved your point wrong, as the WinAPI obviously does NOT check if the time has passed, because it returned early many times. I know, because I was using QueryPerformanceCounter and QueryPerformanceFrequency. Apparently, Sleep would either be calling a Wait function with a handle that will not be signaled ever, with the time passed to Sleep(), OR.... Sleep does take clock cycles and guestimates based off mhz and cycles per a certain instruction.

When there were no SPIKE changes, my version is alot more consistent.

Whose is more accurate?

Albeit, in terms of AFTER the intented .1 second, the most time that was off was one instance by mine being off by .00318167 seconds, that's .003 and a little change, HOWEVER... More often than not, (in fact, 90% of the time in those 100 tests) my function was off by less than .00000500!

And truthfully speaking, the time frame it takes for calling QueryPerformanceCounter after my function returns probably takes up that miniscule amount of time. So, in more likeliness? My function is pretty much 100% correct 90% of the time.

File2.txt is my second test of 50 iterations each of .2 seconds. My results are 94% (47 out of 50) when the same rules were applied.

File3.txt is my third test of 25 iterations of .3 seconds each. Results were with that same rule a result of 92% (23/25).

My last test (File4.txt results) was of 50 iterations of .020 sleeps a piece. The result on mine with the same rules? 45/50 for a 90%.

If this was an issue of 'comparing', I would be saying the following...

Code:

---

unsigned long TextFormatter::OutputDouble(char * pBuffer,double lfValue,unsigned long dwPrecis) throw()
    {
        const long long nDigit = static_cast<long long>(lfValue);
        double lfRemain = lfValue - static_cast<double>(nDigit);

        unsigned long dwOutput = OutputInt64(pBuffer,nDigit);
        pBuffer[dwOutput] = '.';
        ++dwOutput;

        char * pOutput = &pBuffer[dwOutput];
        unsigned long dwTemp;

        for (unsigned long x = 0; x < dwPrecis; ++x)
        {
            lfRemain *= 10.0;
            dwTemp = static_cast<unsigned long>(lfRemain);
            dwTemp %= 10;

            pOutput[x] = static_cast<char>(dwTemp) + '0';
        }

        dwOutput += dwPrecis;

        return dwOutput;
    }

---

Is way faster than sprintf combined with other functions that are similar for the same result. (multiple functions calls faster than one sprintf)

To state my question again...What exactly is your point with this thread?

Do you have problem or are you just posting? Remember that the forums exist to help people with their problems, not post our repertoire.

Quote:

---

Originally Posted by CBasicNet

I don't think this is an 'accurate' form of Sleep(). When the code encounters a Slepp() call, the thread gives up its time slice back to the task scheduler. When it is its time slice again, it checks if it is the time for Sleep() to end and continue execution, if it is isn't, the thread will give up its time slice again, and so on. Sleep() doesn't hog the CPU with this endless loop, afaik.

---

And the thread gets a normal time slice running this loop. Really, no harm done.

As far as having a question, yeah... I do have a question... What if any ways can anyone think of creating a safe 'Wait' version of this function when dealing with implementing my own synchronization objects?

I am basking into the idea of writing a C++ "OS" in abstract, and then later implement the assembly to tie it to the hardware.

The use of QueryPerformanceCounter in my GetCurrentTicks() is an example of that abstraction.

GetCurrentTicks() is the abstract function (in terms of implementation, the interface being concrete - it's only a function) to call to get the performance ticks from the system. (Which on this Windows implementation it calls QueryPerformanceCounter)

James,

If you want to simply share code, then I suggest you write an article or Tip (in the form of a short article) and post it to the main site using the submission form you can find in the left navigation menu (on the main, www.codeguru.com site).

People can comment on such articles or tips as well.

Brad!

It is pretty well know that Sleep is unreliable. Search google for 'Sleep multimedia time precision' for a boatload of information as well as many other articles on the subject.

As far as your posted code, you don't include the code for GetTicksInSecond() but mention it uses query perf counters. However, based on the implementation that is posted, it looks like your Sleep will peg the CPU, as unlike the Sleep api, it doesn't appear to relenquish the thread's time slice. If this is the case, I'm not sure a sleep routine that pegs the CPU is helpful, even if it is more accurate.

Quote:

---

Originally Posted by Arjay

It is pretty well know that Sleep is unreliable. Search google for 'Sleep multimedia time precision' for a boatload of information as well as many other articles on the subject.

As far as your posted code, you don't include the code for GetTicksInSecond() but mention it uses query perf counters. However, based on the implementation that is posted, it looks like your Sleep will peg the CPU, as unlike the Sleep api, it doesn't appear to relenquish the thread's time slice. If this is the case, I'm not sure a sleep routine that pegs the CPU is helpful, even if it is more accurate.

---

Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.

The implementation of GetTicksInSecond() and GetCurrentTicks() are just wrappers for Windows API functions at the moment.

Code:

---

unsigned long long GetTicksInSecond()
{
    unsigned long long value;
    ::QueryPerformanceFrequency(reinterpret_cast<LARGE_INTEGER *>(&value));
    return value;
}

unsigned long long GetCurrentTicks()
{
    unsigned long long value;
    ::QueryPerformanceCounter(reinterpret_cast<LARGE_INTEGER *>(&value));
    return value;
}

---

The reason it may seem to peg the CPU, is that you are probably not running several processes in which there are more 'threads' to pass a time slice. Therefore, the CPU will just stay on that thread for a while, and it also has something to do with the fact that QueryPerformanceCounter takes very little time to execute... Therefore, it runs that loop MANY TIMES before giving up to a time slice. You are just used to the CPU not working that hard before it gives a slice to another thread.

I'll reiterate... Imagine if an application is given a .004 second time slice... And that the call to QueryPerformanceCounter through GetCurrentTicks() only takes 0.00000350 seconds on the average.

What is that? Like 1/119 of the time slice? That loop could conceivably run 100 times before it gives in to the thread scheduler.

I am not giving up any time to the scheduler for other threads... You are probably used to the fact that your app would 'yield time' in which it makes my approach seem like 'eating' clock cycles.

When in actuality, 'TimeSlice'->'TimeSliceUsed' > 'TimeSlice'->'SliceYielded' is how it should be described when thinking about available cycles.

In actuality, I am making more use of my allotted time slice, than the average application... Instead of actually 'wasting' time by allowing the processor to sit dormant.

Does this eat up your CPU so much it's sluggish? It does not this one.

Let me preface this by saying that I'm not trying to argue with you or dismiss your work.

Quote:

---

Originally Posted by JamesSchumacher

Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.

---

Why can't I test one thread? Shouldn't the behavior of a Sleep function work the same whether it's being used in a single or multithreaded app?

I've created a test app that runs your sleep( ). I first ran your sleep( ) in a single thread dialog app and it used 50% CPU. I then ran the same app except used the Sleep( ) api. While sleeping, it consumed 0% cpu.

Out of curiosity, I then added multithreading to the mix. While running your sleep() routine in a separate thread, it used 50% cpu.

See the attached project.

Quote:

---

Originally Posted by JamesSchumacher

The reason it may seem to peg the CPU, is that you are probably not running several processes in which there are more 'threads' to pass a time slice. Therefore, the CPU will just stay on that thread for a while, and it also has something to do with the fact that QueryPerformanceCounter takes very little time to execute... Therefore, it runs that loop MANY TIMES before giving up to a time slice. You are just used to the CPU not working that hard before it gives a slice to another thread.

---

You're a little off base here. This statement:

"Therefore, it runs that loop MANY TIMES before giving up to a time slice."

is incorrect. You are mistaken how a pre-emptive OS works. The code doesn't ever control how long it gets to run, that's the scheduler's job.

The scheduler will run your code for a time slice as determined by the system and then switch to another thread. Whether your thread is caught in a infinite loop and spinning is of no importance to the OS. In this case, your sleep function essentially is running wild during it's time slice and that's why it's consuming high CPU %. The scheduler will preempt your thread (and does preempt your thread ) many times while it's running although it may not appear to be doing so.

Whether this occurs in a single thread or a multiple thread is irrelevant because the high CPU utilitization of your function occurs in either case. The OS doesn't care if a thread burning up the CPU is the main thread of an app or a secondary thread - it still burns up the cycles.

What the api Sleep() does is that while sleeping, it goes into an efficient sleep state so the OS just skips over the thread (i.e. doesn't schedule any time slices during the same sleep period). That is quite a bit different than spinning while waiting for the time period to expire.

Quote:

---

Originally Posted by Arjay

Let me preface this by saying that I'm not trying to argue with you or dismiss your work.



Why can't I test one thread? Shouldn't the behavior of a Sleep function work the same whether it's being used in a single or multithreaded app?

I've created a test app that runs your sleep( ). I first ran your sleep( ) in a single thread dialog app and it used 50% CPU. I then ran the same app except used the Sleep( ) api. While sleeping, it consumed 0% cpu.

Out of curiosity, I then added multithreading to the mix. While running your sleep() routine in a separate thread, it used 50% cpu.

See the attached project.

You're a little off base here. This statement:

"Therefore, it runs that loop MANY TIMES before giving up to a time slice."

is incorrect. You are mistaken how a pre-emptive OS works. The code doesn't ever control how long it gets to run, that's the scheduler's job.

The scheduler will run your code for a time slice as determined by the system and then switch to another thread. Whether your thread is caught in a infinite loop and spinning is of no importance to the OS. In this case, your sleep function essentially is running wild during it's time slice and that's why it's consuming high CPU %. The scheduler will preempt your thread (and does preempt your thread ) many times while it's running although it may not appear to be doing so.

Whether this occurs in a single thread or a multiple thread is irrelevant because the high CPU utilitization of your function occurs in either case. The OS doesn't care if a thread burning up the CPU is the main thread of an app or a secondary thread - it still burns up the cycles.

What the api Sleep() does is that while sleeping, it goes into an efficient sleep state so the OS just skips over the thread (i.e. doesn't schedule any time slices during the same sleep period). That is quite a bit different than spinning while waiting for the time period to expire.

---

That is true... However... I am not just concerned with Sleep(), I was concerned more with the accuracy of timing. Timers work in different ways on Windows depending on the implementation, and because of the fact that Sleep() goes into a 'wait state' there is that issue of a waitable timer for example not being 'accurate'.

This is more along the lines of accuracy than clock cycles.

In that application that I posted a link to (the folder link) I use a similar loop. I will use a similar loop design when I write a game. (However, I am going to be a little more 'efficient' when I write that game. At 30 fps (my target) I can afford to Sleep() or wait on a dummy mutex or something for 1 millisecond. Then I can run this type of loop until the time 'expires'. Although, when relinquishing time for 1 millisecond, I might get a slice 5 milliseconds later or whatever... So I might just use the loop to ensure accuracy.

Your version of sleep is totally environment-unfriendly, in view of the global warming crisis. Wasting CPU cycles for doing nothing. When we use Sleep(), very rarely we need that kind of accuracy and precision, we just want to sleep while waiting for a response(not event based), when the sleep is over, the response is not ready, we sleep again. For that kind task, Sleep() is sufficient.

Imagine 1 million users are playing your game where their PC specs could have attain more than 30fps or even 60fps but you limit it to 30fps for no good reason and use full CPU utilization when that thread is running or sleeping(pun intended). Colossal waste of electricity!

Quote:

---

Originally Posted by JamesSchumacher

Try it when it's not the only thread in your application. It does not peg the CPU, all other threads get the appropriate time slice. You cannot just test one thread.

---

It uses *all* the CPU it can.

For example, if you compress a file while this sleep function is running, it'll compress TWICE as slow (unless you've a dual core or multiprocessor machine).
It's even funnier if you set the priority of your thread to something above other threads. It'll hang the whole system during the whole sleep operation!

You should:

• Immediately confess.
• Become a hermit and pray during the rest of you life.
• Hope that your sin will be forgiven.

If you need an accurate timer, use multimedia timers.

Very few programs do abominations like you did. I immediately uninstall these awful programs.

You could render your abomination less abominable by waiting N-50 milliseconds and use your horror for the last few milliseconds. It would still be evil, but less evil.

Quote:

---

What is that? Like 1/119 of the time slice? That loop could conceivably run 100 times before it gives in to the thread scheduler.

---

Yes. It eats more than 100, 1000 or 10000 times the CPU required.

Quote:

---

I am not giving up any time to the scheduler for other threads... You are probably used to the fact that your app would 'yield time' in which it makes my approach seem like 'eating' clock cycles.

---

Exactly.
An application that eats all the CPU the system accepts to give to it only to do NOTHING should be immediately killed.

On modern computers, even video players aren't that unfair!

On a normal system, when desktop applications are used, only a few percents of the CPU are used.

On laptops you eat battery power.

Quote:

---

Instead of actually 'wasting' time by allowing the processor to sit dormant.

---

It is not wasted.
It is either used to save batteries, or used by OTHER PROGRAMS.

You're still thinking as if you were using a monotasking OS.
On a desktop computer, I want to be able to compress three files at once, and yet, use normally my computer.

Often, when working with desktop applications without background tasks, only a few percents of the CPU are used, indeed.
But, what if all the programs adopt your awful behavior?

Then, any tiny application-that-does-nothing will claim to need all the CPU it can have.

If twenty processes do that, we'll end up getting files compressed twenty times slower... Moreover, these programs will entirely loose their accuracy, because they'll execute their loop only 1/20th of the time... Something like once every 200 milliseconds (assuming the max time slice is 10 milliseconds).

Quote:

---

lthough, when relinquishing time for 1 millisecond, I might get a slice 5 milliseconds later or whatever...

---

Actually, the time slice will, in average, be equal to the inaccuracy of Sleep(). So, just use Sleep().

Anyway, for a 30 fps game, Sleep()/WaitFor* are sufficiently accurate.
If you feel that you need more accuracy, use multimedia timers. With them, you can CHOOSE the accuracy. Something like 4 or 5 milliseconds should be ok.

In practice your game will never be smooth with this fixed-framerate approach, because:

• Very fast machines won't ever have more than 30 fps in your game.
• Medium and slow machines may need more than 1/30th of second for some images but not all, which will give the bad feeling that your game has a variable speed.

If you use an ID software game, you can experience this bad feeling when setting the min and max fps values to the same number. With the same computer, you'll feel that it's far less smooth than with a variable framerate than with a variable framerate.

Moreover, with a variable framerate, accuracy of Wait* operations is not needed anymore since if the time waited is five milliseconds more than planned, the game world will take that time in account for its next move.

A variable framerate game should have:

• A min fps value. If the physical time to compute one frame is longer than 1/min-fps, then, the game time spend in this frame must be set to 1/min-fps
• A max fps value. If one frame is computed in less than 1/max-fps, the game will wait (with Sleep or WaitFor*) for 1/max_fps - time_that_was_spent_to_compute_the_frame.
• A user setting to change max fps and min fps values.

Then, instead of making the world move by constant steps, you should make everything a variable of the game time spent between two frames.

Quote:

---

Originally Posted by CBasicNet

Imagine 1 million users are playing your game where their PC specs could have attain more than 30fps or even 60fps but you limit it to 30fps for no good reason and use full CPU utilization when that thread is running or sleeping(pun intended). Colossal waste of electricity!

---

Especially for laptops for which every joule eaten decreases the laptop autonomy and the battery lifetime.
To save power, many laptops run the CPU at a variable frequency. If all the CPU power is eaten, the frequency will raise and much more power will be eaten.

Apparently you did not get the just of what I said, I do not Sleep() in my games or run this exact loop of doing 'nothing'.

I simply stated that I wrote a similar loop to this that also does OTHER operations.

For example:

Code:

---

do
{
    if (TimeHasPassed)
    {
        GameObject->Cycle();
    }
} while (true);

---

I said a similar loop - I did not say I was using a 'nothing' loop.

So when you say that I am wasting 'cycles', you are wrong. The reason being in the sense of what I just decribed. When someone plays a game, they have very little intention of doing much else... So think about what your point was against what I just said.

Which was my point about the 'faster code' versus sprintf.

Timers are inaccurate as the Sleep() function, THAT is my point. Windows is not a REALTIME OS.

The structure of my code in terms of accuracy is what I meant. In 'structure' where a similar loop (relative to all code) such as the example above - for ACCURACY, to ensure what I want to happen is done correctly. You stated that in your own post, which is WHAT I MEANT in my post previously. What you just did is take my idea of what I said, and acted as if I did not intend that - in a way, not to sound like I am 'baiting', but that I 'do not know what I am talking about.' When in fact I do.

A dummy Wait() would be a solution to allow some other process some clock time, and NOT wait for the entire period between 'Cycles'. A dummy wait for a portion, and this 'looping' until it's time to cycle.

As for the laptop issue... Yes, you are correct. That is common sense. It's just like sampling audio at 48000 instead of 44100, it takes up more harddrive space.

About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call. Kernel code has priority over user mode code. And, by looping in this manner, creating that priority boost - I can get 'more cycles' for my thread, in which when the time comes to Cycle(), those cycles will be used for the game itself. Which means it will actually run SMOOTHER.

I can also take advantage of this in a worker thread, when it's time to do something, have that thread post to the Waiting() GUI thread (GetMessage() sits there and waits for a message to be inserted into the queue, therefore when the event is set that one has been, it gets a BIG priority boost, and even bigger still - the priority boosted thread that called SendMessage adds the priority to that thread, because it is the thread that sent the message.)

This has it's pros and cons. More pros than cons actually. You want to get a task done as quickly as possible, then you can allow things to be done by other tasking 'objects'.

This is actually a good solution in terms of writing a 'time critical' application due to the fact of using up cycles. GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue. So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones. That is why I witness no apparent downside in my testing. The GUI threads get a large priority boost when an event is inserted into the queue - therefore, what's the problem?

Example:

Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond) I wrote a sampling app (note the word sampling, not polling like a standard GUI application) that all it did was get the desktop window DC, and painted text on it that was different colors every time. I set it to try and go as many frames as possible (10000).

It only mustered at most 900 FPS.

However, when I changed this to use QueryPerformanceCounter? I was able to muster 9600 FPS.

Quote:

---

Originally Posted by JamesSchumacher

Apparently you did not get the just of what I said, I do not Sleep() in my games or run this exact loop of doing 'nothing'.

I simply stated that I wrote a similar loop to this that also does OTHER operations.

For example:

Code:

---

do
{
    if (TimeHasPassed)
    {
        GameObject->Cycle();
    }
} while (true);

---

I said a similar loop - I did not say I was using a 'nothing' loop.

So when you say that I am wasting 'cycles', you are wrong. The reason being in the sense of what I just decribed. When someone plays a game, they have very little intention of doing much else... So think about what your point was against what I just said.

Which was my point about the 'faster code' versus sprintf.

Timers are inaccurate as the Sleep() function, THAT is my point. Windows is not a REALTIME OS.

The structure of my code in terms of accuracy is what I meant. In 'structure' where a similar loop (relative to all code) such as the example above - for ACCURACY, to ensure what I want to happen is done correctly. You stated that in your own post, which is WHAT I MEANT in my post previously. What you just did is take my idea of what I said, and acted as if I did not intend that - in a way, not to sound like I am 'baiting', but that I 'do not know what I am talking about.' When in fact I do.

A dummy Wait() would be a solution to allow some other process some clock time, and NOT wait for the entire period between 'Cycles'. A dummy wait for a portion, and this 'looping' until it's time to cycle.

As for the laptop issue... Yes, you are correct. That is common sense. It's just like sampling audio at 48000 instead of 44100, it takes up more harddrive space.

About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call. Kernel code has priority over user mode code. And, by looping in this manner, creating that priority boost - I can get 'more cycles' for my thread, in which when the time comes to Cycle(), those cycles will be used for the game itself. Which means it will actually run SMOOTHER.

I can also take advantage of this in a worker thread, when it's time to do something, have that thread post to the Waiting() GUI thread (GetMessage() sits there and waits for a message to be inserted into the queue, therefore when the event is set that one has been, it gets a BIG priority boost, and even bigger still - the priority boosted thread that called SendMessage adds the priority to that thread, because it is the thread that sent the message.)

This has it's pros and cons. More pros than cons actually. You want to get a task done as quickly as possible, then you can allow things to be done by other tasking 'objects'.

This is actually a good solution in terms of writing a 'time critical' application due to the fact of using up cycles. GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue. So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones. That is why I witness no apparent downside in my testing. The GUI threads get a large priority boost when an event is inserted into the queue - therefore, what's the problem?

Example:

Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond) I wrote a sampling app (note the word sampling, not polling like a standard GUI application) that all it did was get the desktop window DC, and painted text on it that was different colors every time. I set it to try and go as many frames as possible (10000).

It only mustered at most 900 FPS.

However, when I changed this to use QueryPerformanceCounter? I was able to muster 9600 FPS.

---

I would like to add one more thing...

The only way to ensure something is done 'on time' or very close to 'on time' is to pretty much 'demand' more cycles/clock time. This ensures that the code (well, not ensure, but come closer to the intended timing target) begins executing at the target time.

In designing a game, you want to base it off input of the user, but with the mindset that you are sampling at a certain framerate. Games require that code do not take very long to execute in their minute selves, as a whole - the calling of all those functions, etc... must add up to less than the intended cycle time for a frame, otherwise... It will run at a slower framerate than the target. In order to make sure that code starts executing at the desired timestamp, it is necessary to demand more of the CPU and that could mean running a loop that only takes .00000009 seconds to execute, unless a time period has passes, and then it might take .00257865 seconds to execute. (This would be a target of 385 - 395 frames per second for a small game, in reality - you would not run this many frames)

The reality to hit the target framerate is to get as much CPU as you can if your code takes a little bit to execute. And by doing so, querying that performance counter in an endless loop (that is until a certain requirement is met) means that compared to all 'waiting threads' it gets the most clock time. And therefore, more clock time when it comes time to Cycle().

A smoother game operation. A little more intensive 'example' I wrote with QueryPerformance functions I always was at 60fps (the target). However, with GetTickCount() it varied as much as down to 44FPS. Ask yourself why.

The only time the average FPS dropped from 60 was when it had to process a window message from the queue. (PeekMessage returned a non-zero value - due to moving of the window) That was due to looping through until PeekMessage returned zero so all window events were handled before checking for time to Cycle(). I could have made it handle only one event if any through the loop, but I wanted to ensure all window events were handled before the next Cycle().

You have to remember...

In a single CPU machine, only 1 thread can be executing at any one time (although for such a minute time, it seems like everything is going at the same time) so when my thread is using cycles, it's technically not robbing from any other. IN FACT, it means they get fewer 'sessions' of cycles, but they get a longer time slice. Higher priority threads get 'more' sessions, with a smaller slice. Lower priorities get a LARGER slice less often. That is how threads are implemented on windows.

Smaller sections of slices more often allows for more 'accuracy' in the sense I have more opportunities to keep the 'time base' correctly synchronized.

That is why in certain situations why it might seem to YOU that it is deadlocking the CPU... Because in actuality - it gives more of a timeslice on a thread that is not intensive or doing much. It will use that alloted time slice to try and go back and forth between all those Waiting threads doing nothing.

It's not my applications fault - it's the design of the OS. That larger time slice gets devoted to checking all those waiting threads that are doing nothing. Therefore, it will come back to my app. My app in that situation due to the OS's design, is what is keeping the CPU actually doing something.

So this design pattern, actually defeats the problem in the design of the OS in intensive situations...

The FUTURE of computing if the programmers are smart, will be based off utilizing the CPU more often and detecting states of 'idle' to precalculate things that a user would want done instead of waiting for 'on demand'. An example of this, would be software that keeps track of scheduled flights. This software could be combined with weather tracking libraries in order to be able to predetermine what flights might be delayed long before the flight even gets scheduled.

Although, in GENERAL... You can plan for a flight months in advance, in which we cannot predict the weather... Imagine, 6 days before a flight in which a 'person' cannot deduct without the information as soon as it's available, that it will be delayed... Could create a situation (the need) for informing passengers that their flight may be delayed instead of waiting until the day of or the day before.

So it's more in the sense of before the scheduled flight would take off, but still... It's that IDEA.

If the person was to know 6 days in advance the flight might be delayed... They could have a chance to make preparations or other plans/cancel flight if it was a pertinent/important matter they were to attend.

You might think that something as small as a time slice wouldn't matter... It does in fact... Imagine what I said about sprintf versus my custom. The sprintf was in fact something like 25 or more times slower. Which is the difference between processing a million things in a loop in like 1 second, and 25 seconds.

sprintf is/was a standard C library function. They tell us it is not good to reinvent the wheel, when in fact reinventing the wheel can greatly aid in time saving, which in turn, like the above... Helps immensely if you were traversing a multi-megabyte / gigabyte file. (Think databases)

Think about a text parsing function like sscanf, sprintf scanning cousin. Imagine the SAME situation.

In fact, this is what Microsoft does not realize. With the invention of faster CPUs and more resources, Microsoft has 'jumped' the gun so to speak in terms of 'estimation' by creating 'managed' languages. Do they not realize the reason as to why JAVA failed to be as big as Sun Microsystems wanted? It's the fact the majority of Java implementations are not NATIVE based. The slow code. It's that simple.

People do not realize, most things take very little time to process... HOWEVER... Larger, more time consuming actions use these smaller actions to do a portion of the larger task... That is why when someone sits there waiting for 45 seconds for an operation to be completed, that same task COULD HAVE BEEN done in like 1/3 of the time.

Microsoft taking that plunge with a JIT for platform independency, when in fact for the most part, .NET is Windows only.... Has introduced and multiplied that problem... The consumer complains about things not being done in a timely fashion... .NET managed code (even installed in the CACHE as native) inflates this problem.

What Microsoft SHOULD HAVE DONE for a better OOP programming library, would be to rewrite Windows as an exposed OOP operating system. In this manner, the OOP approach to the OS in terms of a programmer, is as close to the hardware as possible without compromising security of the system.

The SAME TYPE of thinking will be Apple's boom downfall. The music industry is like a roller coaster, it comes and goes... Apple is taking advantage of the current boom, and focusing almost entirely on music... Jobs and his company will hit a reality awakening wall sometime in the near future.

Apple is not thinking of the future, they are thinking of now.

In a little bit of philosophical matter relating to the same issue...

Society has allowed itself to deteriorate and even preparing to chain itself up in locks and chains. What do I mean by that statement?

There is a thinking in the world today, that has been happening for a long time...

Look around you. So many religious based things... People do not realize how much... Without going into too much detail... Alot of society today... There is some person in this country that was held down throughout his life... And albeit not the entire societies fault, but a large portion (not majority, a large portion) and a part of that was due to a conspiracy in which was about religion. It has to do with a thinking of create chaos--->leave clues--->person exposes it.

The dependency and life living on that line of thinking... What happens when that <----> person <----> accomplishes the exposal of things in the government that was intended in the first place?

The learning of society to live in the way they do, will chain itself up... Because that is the only way they have known to live.

Computer industry will even be affected. The music industry has ALOT based off religious matters... With this removal of that line of thinking, when that knight of God does what was intended... Will find that with the proof of existence of that God... And they learn the truth the chaos in the world was not at all God's intention... Or that 007 conspiracy... Where does the inspiration for that music come from from that point?

When those people learn the truth about what our creator through the 5th dimension of evolution discover this... Their careers will be affected greatly.

Which is the reason behind God's warnings throughout the history of mankind on what it is doing to itself. Along with the other things he was trying to get people to realize NOT TO DO.

Creating of situations is like theatre... Although reality in the chaos they create, the celebratory manner in which thinking of 'to conquer in the final battle' thinking... Do people stop and think about that for one second? What are they to do with their careers if that is how they make their money?

And it's also to think on the other end of the stick... Those that made money for themselves through the conspiratory things in society. They will lose out, even more so. In addition to maddening God.

Quote:

---

Code:

---

do
{
    if (TimeHasPassed)
    {
        GameObject->Cycle();
    }
} while (true);

---

---

This code is equivalent to:

Code:

---

do {
  GameObject->Cycle();
  AbominableSleep(frame_time - time_to_compute_the_cycle);
} while(true);

---

Quote:

---

When someone plays a game, they have very little intention of doing much else

---

Wrong.
They can still compress files in background.
And if they don't, they may not like to see their battery power vanish if they use a laptop computer.

Quote:

---

So when you say that I am wasting 'cycles', you are wrong.

---

No, you are WASTING CPU cycles. If GameObject->Cycle() takes, say, 10 milliseconds and your game runs at 30 fps, then, your program will try to use 3.3 times more CPU cycles than needed.

Quote:

---

About what you said about a thread priority boost, that is due to the QueryPerformance functions, they are probably making a kernel call.

---

No, I was talking about an hypotetical case where someone would manually boost the priority of your process and notice that normal priority processes (e.g. explorer) are frozen forever.

Quote:

---

Which means it will actually run SMOOTHER.

---

If you think that you get an artificial priority boost, then, it's a shame, not an honor.

Quote:

---

GUI threads generically do not use many cycles, they wait until an event has been inserted into the queue.

---

Which is a good behavior.

Quote:

---

So I say, why not use as many cycles as I can, considering the importance of GUI applications over console ones.

---

Because MY COMPUTER IS NOT MONOTASKING.

Assume that my computer is much faster than required for your game.
I compute every frame in 1 millisecond.
Assume that I compress a big file, using as much CPU power as it can, and I run your game.

If your game used Windows Sleep() operation; My compression operation will be very very slightly slowed down. Every 30 milliseconds, it'd loose 1 millisecond.
If your game use this do-while loop, it'd claim that it constantly needs CPU, and my compression operation will be exactly TWICE slower than normal.

Quote:

---

That is why I witness no apparent downside in my testing.

---

Because you use your system like a monotasking system.

Quote:

---

Using GetTickCount() previously (which is horrendously inaccurate, it can be off my 1 millisecond)

---

timeGetTime() has the accuracy of 1 millisecond.

BTW, what is the point of eating all the CPU if you want a fixed frame rate?

Quote:

---

In a single CPU machine, only 1 thread can be executing at any one time (although for such a minute time, it seems like everything is going at the same time) so when my thread is using cycles, it's technically not robbing from any other.

---

You definitively don't understand what cooperation between threads mean.
You're not really stealing, as the system accepts to give you what you ask, but you're asking more than you need.

Suppose there is a big cake.
Two persons want to eat the cake.
But YOU are allowed to take a part of the cake, because the law says so.
However, suppose that you've just eaten for the dinner and aren't hungry anymore to the point that you cannot eat anything anymore.

If you're a good man, you'll say to the two men: "Cut the cake in two and take the two parts. I won't take my part. I'm not hungry".
If you're not a good man, you'll say: "Cut the cake in three and give my part", then, you'll drop your part on the floor and jump with your two feet right on it so that REALLY nobody will ever benefit from it.

This is the game you're playing with the CPU. The CPU is a cake. You shouldn't claim that you need to eat it if you don't.

Quote:

---

Games require that code do not take very long to execute in their minute selves, as a whole - the calling of all those functions, etc... must add up to less than the intended cycle time for a frame, otherwise... It will run at a slower framerate than the target.

---

A proper Sleep() operation in a variable framerate game doesn't prevent that.
Maybe you never played to GlQuake?
This is instructive.

Quote:

---

It's not my applications fault - it's the design of the OS.

---

No. Your application is too badly programmed to have a variable framerate. This is its fault.
BTW did you search MSDN for multimedia timers?

Quote:

---

My app in that situation due to the OS's design, is what is keeping the CPU actually doing something.

---

Mhhh... How do you think that GlQuake is perfectly smooth and yet, don't eat my CPU? Is it some sort of black magic?


Anyway, I feel that the discussion won't go anywhere.

Could you give the name of your application(s) so that I can avoid to ever install it on my computer?

Then tell me...

How do you write a game that needs accuracy of better than a millisecond?

WaitFunctions will not help you out.

timeGetTime has a resolution of 1 MILLISECOND.

And the answer to your question is simple - it answers mine as well. Those games? I would bet run something like my loop for a little while, then API::Sleep() to give the other threads more time, then back to what I do.

THAT is how they would do it.

Keeping track of time LESS than one millisecond.

Hi All!

Here my personal solution which is working in industrial multithreaded environment since several years now:

File PnSleep.h:
class CPnSleep
{
public:
CPnSleep(BOOL bFullResolution = FALSE);
virtual ~CPnSleep();

BOOL Sleep(UINT ms);

protected:
HANDLE m_hEvent;
BOOL m_bFullResolution;
};
File PnSleep.cpp:
CPnSleep::CPnSleep(BOOL bFullResolution):
m_bFullResolution(bFullResolution)
{
m_hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
}

CPnSleep::~CPnSleep()
{
CloseHandle(m_hEvent);
}

BOOL CPnSleep::Sleep(UINT ms)
{
BOOL bRet = TRUE;
MMRESULT mmResult = timeSetEvent(ms, m_bFullResolution ? 0 : ms/10, (LPTIMECALLBACK)m_hEvent, NULL, TIME_ONESHOT | TIME_CALLBACK_EVENT_SET);
UINT nWait = ms > 42 ? 42 : ms;
UINT nElapsed = 0;
while(WAIT_OBJECT_0 != WaitForSingleObject(m_hEvent, nWait))
{
nElapsed += nWait;
if(nElapsed > ms)
{
bRet = FALSE;
break;
}
}
timeKillEvent(mmResult);
return bRet;
}

bFullResolution:
A resolution of 0 indicates periodic events should occur with the greatest possible accuracy. To reduce system overhead, however, you should set bFullResolution = FALSE.


Any comments are welcome !

Why 42 ? Please find the answer at:
http://en.wikipedia.org/wiki/The_Ans...and_Everything

Bye, bitbo

Quote:

---

I would bet run something like my loop for a little while, then API::Sleep() to give the other threads more time, then back to what I do.

---

No.
They don't loose CPU cycles they don't need.

They do something like:

Code:

---

Time t1=GetAccurateTime(); /* internally use QueryPerformanceCounter ONCE */
/* assume that the Time object has overloaded operators */
for(;;) {
  Time t2=GetAccurateTime();
  Time tdiff=t2-t1;
  if (tdiff < 1/max_fps) ::Sleep((1/max_fps - tdiff).toMilliseconds()); /* This DOES NOT need to be accurate... as far as it waits less than 2*(1/max_fps-tdiff) and more than (1/max_fps - tdiff)... The game will still have the max frame rate */
  if (tdiff > 1/min_fps) tdiff=1/min_fps;
  t1=t2;
  ComputeFrame(tdiff); /* tdiff is the time difference between two frames to be taken in account for movements of entities */
}

---

To get a smooth game, max_fps should be set to something like 80 or 90 (ideally a user setting as in Quake II and Quake III). Setting a higher max_fps is useless as it would be higher than the screen frequency.
Or there may be a different frame rate for the physical computations and the visual computations, in that case there should be two max_fps and min_fps values.

Quote:

---

Originally Posted by JamesSchumacher

How do you write a game that needs accuracy of better than a millisecond?

---

Using QueryPerformanceCounter, but calling it only ONCE for every frame.
QueryPerformanceCounter(), timeGetTime(), GetTickCount()... All these functions eat very few CPU cycles if they're only called ONCE.
GlQuake use QueryPerformanceCounter(). Quake II uses timeGetTime().

BTW: Calling QueryPerformanceCounter() doesn't change the thread priority. If you need to change the priority call SetPriorityClass().
However, doing things such as an empty loops (if others program don't behave badly, unlike yours) has an effect on the probability that your thread is currently executing when you need something.

Analogy with the cake:
Assume that there's a big unlimited cake, but only one person can eat a piece of it at a time, because it must respawn.
Everybody (EXCEPT you) is nice and eat the cake only when he needs to.

Anybody gets the right to eat some part of it. However there's a queue to the cake.
To limit (but not totally prevent) abuses, nobody can eat the cake more than twenty seconds UNLESS he's the only one in front of the cake.
So, for example, if there're three persons on the queue and all of them need to eat the cacke 60 seconds, the first one will eat it 20 seconds, than the second one, than the third one, and back to the first one. There'll be 3 cycles before everybody gets the cake he needed.

Now, YOU noticed that very few people eat the cake TODAY... Most of the time, the queue is empty. Nobody eats the cake at all!
You noticed that, sometimes you need to eat the cake... But, sometimes (e.g. 10% of the time), there's somebody in front of the cake and you need to wait between 1 and 3 seconds that he finishes his part of the cake (because most people don't need 20 seconds to take their part of the cake), then, you eat your part.

Then, you had the idea of camping in front of the cake... Now, if somebody come (which happens sometimes), you'll not give your place before some time (between 0.00000000000000001 second and 20 seconds: Note that you have absolutely NO guarantee about the duration of this time... You just have a high probability (95%) that it be larger than 1 second) since you're currently in a time slice so that, if you need the cake at this exact time, you'll get it immediately instead of waiting for 1 to 3 seconds.

First, notice that your behavior is already bad for other people (who are much more numerous than you): Instead of getting immediately their part of the cake 99% of the time (with 1% of probability of having to wait for the queue), they'll wait 1 to 20 seconds in average.

Secondly, if OTHER people become evil like you, they'll all camp in front of the cake to get as much "cake time" they can. Then the queue will become huge all the time (say 100 persons), and you'll get the cake only 20 seconds every 100*200=20000 seconds. In other words, you'll WAIT lots more than needed.

Queues work, because only people who need the service provided at the end of the queue use the queue.

If everybody went to the every queues: "Just in the very improbable case I need the service when I get to the end of the queue", then, queues would become much less efficient.

Quote:

---

UINT nWait = ms > 42 ? 42 : ms;

---

Why do you block on WaitForSingleObject at most 42 milliseconds? To be in front of the cake more time? Being in front of the cake once every 42 milliseconds is probably insufficient, anyway.
If you want to... Then, at least, you should play this trick only the 42 last milliseconds of a wait operation.
e.g. If you wait 100000 milliseconds, then, do a WaitForSingleObject for 100000-42 milliseconds, and then, a second WaitForSingleObject for 42 milliseconds.
Anyway, I don't think that it'll work better than WaitForSingleObject(m_hEvent, INFINITE).

Quote:

---

nElapsed += nWait;

---

Don't do that. Biais will be added up. i.e. If in average, WaitForSingleObject returns one millisecond before than the wait time, for 4200 milliseconds, you'll wait 4100 milliseconds in average.
Moreover, absolute inaccuracies (random variations around the wait time, not biaised on a particular side) will approximatively grow as the square root of the time you wait instead of being constant.

You should rather compute the time difference between the base time and the current time at every iteration:

Code:

---

DWORD time0=timeGetTime();
while(WAIT_OBJECT_0 != WaitForSingleObject(m_hEvent, nWait))
{
if ((timeGetTime() - time0)>ms) {bRet=FALSE;break;} /* warning: Will probably return FALSE easily... I'd rather return TRUE than FALSE... */
}

---

Instead of a while loop, try that:

Code:

---

bRet = WAIT_OBJECT_0 == WaitForSingleObject(m_hEvent, INFINITE));

---

If you want to get a time slice immediately (which may be quite unfair unless your app controls device drivers and has to be a real time app), you may call SetPriorityClass() to set a HIGH_PRIORITY_CLASS.
In that case, when at the millisecond the event is occurs, Windows will STOP normal priority processes even if one of them is in a CPU intensive loop, and immediately give the time slice to your program, and won't give the CPU back to the normal priority process before you enter in a blocking call again (e.g. WaitForSingleObject).

Theorically, you could also call SetPriorityClass with HIGH_PRIORITY_CLASS immediately before WaitForSingleObject and with NORMAL_PRIORITY_CLASS immediately after WaitForSingleObject, so that you immediately get the time slice when the wait operation finishes, but, you won't have any guarantee that your time slice will lasts more than 5 nanoseconds... In other words, it makes little sense.

Quote:

---

Originally Posted by JamesSchumacher

Then tell me...

How do you write a game that needs accuracy of better than a millisecond?

Keeping track of time LESS than one millisecond.

---

Since when is your sleep has accuracy of better than a millisecond? Your sleep accuracy depends how much time your work item, which you execute in your sleep function, complete its work. If your work item use more than a millisecond, then too bad for your game! Let's say your work item use 0.55 millisecond, on the second loop it would exceed 1 millisecond, oops not accurate anymore. If the fps is less than 60 fps on a particular PC without the need for sleep, your work item don't get to execute, and your game is screwed because it is hardcoded to run everything in 60fps exact, not less. Your game is assumed to run on a PC which can run it faster than 60 fps, so that your sleep/wait code can work. What if your work item don't get to execute? Is it okay? If it is okay, then it is something isn't worth doing. If it is worth doing, start a thread to do it, rather than do it in your sleep.

Quote:

---

Originally Posted by JamesSchumacher

Then tell me...

How do you write a game that needs accuracy of better than a millisecond?

WaitFunctions will not help you out.

timeGetTime has a resolution of 1 MILLISECOND.

And the answer to your question is simple - it answers mine as well. Those games? I would bet run something like my loop for a little while, then API::Sleep() to give the other threads more time, then back to what I do.

THAT is how they would do it.

Keeping track of time LESS than one millisecond.

---

It is not accurate anymore if you use ::Sleep(). In your scheme, if you only utilise ::Sleep() for period longer than 1 millisecond, then your scheme is only accurate for period less than 1 millisecond.

Quote:

---

Originally Posted by CBasicNet

Since when is your sleep has accuracy of better than a millisecond? Your sleep accuracy depends how much time your work item, which you execute in your sleep function, complete its work. If your work item use more than a millisecond, then too bad for your game! Let's say your work item use 0.55 millisecond, on the second loop it would exceed 1 millisecond, oops not accurate anymore. If the fps is less than 60 fps on a particular PC without the need for sleep, your work item don't get to execute, and your game is screwed because it is hardcoded to run everything in 60fps exact, not less. Your game is assumed to run on a PC which can run it faster than 60 fps, so that your sleep/wait code can work. What if your work item don't get to execute? Is it okay? If it is okay, then it is something isn't worth doing. If it is worth doing, start a thread to do it, rather than do it in your sleep.

---

The idea in this Sleep() is not the implementation here in the timing method of milliseconds, that can be modified.

The idea in accuracy is choosing what the accuracy level is. That can be changed very easily.

Code:

---

void SleepInMicroseconds(unsigned long long dwMicroSeconds)
{
    const unsigned long long nTicksInSecond = GetTicksInSecond();
    const unsigned long long nTicksInMicro = nTicksInSecond / 1000000;
    // etc....
}

---

See the documentation for QueryPerformanceFrequency. It's the function to query the tick frequency of the high resolution counter of the system if one exists. All newer systems will support a high resolution counter.

Quote:

---

Originally Posted by JamesSchumacher

The idea in accuracy is choosing what the accuracy level is. That can be changed very easily.

---

What good is the accuracy if the loop can't complete within the time period? Earlier your responses were to defend code that spun stating that you needed to use the available processor power, because "why not use it?" to paraphrase. Do you still believe this is a good idea?

Quote:

---

Originally Posted by Arjay

What good is the accuracy if the loop can't complete within the time period? Earlier your responses were to defend code that spun stating that you needed to use the available processor power, because "why not use it?" to paraphrase. Do you still believe this is a good idea?

---

If the application is the only thing running OR the other apps in the background have no worker threads... Then yeah.

There is also another reasoning behind this technique, however it's not loop related.

Consider the following:

Code:

---

class GameTimer
{
public:
    GameTimer(void (__stdcall * Callback)(),unsigned long milliWait) : CallbackFunction(Callback)
    {
        TicksInSecond = GetTicksInSecond();
        TicksInMillisecond = TicksInSecond / 1000;
        MillisecondsToWait = milliWait;
        TotalTickWait = TicksInMillisecond * milliWait;
        PreviousTicks = 0;
        CurrentTicks = GetCurrentTicks(); // so we do not mess up on PreviousTicks
        TicksPast = 0;
    }
    ~GameTimer()
    {
    }
    // The following will be called by GameObject->Cycle()
    void Cycle()
    {
        PreviousTicks = CurrentTicks;

        CurrentTicks = GetCurrentTicks();

        const unsigned long long nDifference = CurrentTicks - PreviousTicks;

        TicksPast += nDifference;

        if (TicksPast >= TotalTickWait)
        {
            (*CallbackFunction)();
            TicksPast = 0;
        }
    }
private:
    void (__stdcall * CallbackFunction)();
    unsigned long long TicksInSecond;
    unsigned long long TicksInMillisecond;
    unsigned long long MillisecondsToWait;
    unsigned long long TotalTickWait;
    unsigned long long PreviousTicks;
    unsigned long long CurrentTicks;
    unsigned long long TicksPast;
};

---

The idea here is that whenever the GameObject->Cycle() method is called, it will run through it's timers in a collection and call each timer's own Cycle() method.

Quote:

---

Originally Posted by JamesSchumacher

If the application is the only thing running OR the other apps in the background have no worker threads... Then yeah.

---

This statement implies that it should matter if any background application have more than one thread. Do you think the OS cares if it's scheduling 1 app with 9 worker threads or 10 separate single-threaded apps?

Quote:

---

Originally Posted by Arjay

This statement implies that it should matter if any background application have more than one thread. Do you think the OS cares if it's scheduling 1 app with 9 worker threads or 10 separate single-threaded apps?

---

Actually, yes it does... That's what the SetPriorityClass() (I think that is the one) function is for. Setting the PROCESS PRIORITY.

And it's all solved simply by this:

Code:

---

**************** README ****************

ETC........................................................................

NOTE: It is highly recommended that you run
this game without any other application running.

---

The point of the matter is this... Say I want 50 fps in a 2D game, that is not asking very much. Okay... A Windows API media timer would probably work great right here as each frame has .020 seconds in between. For a 2D game, 100 FPS wouldn't be asking much... (PROBABLY)

The point of the matter is this...

In a full hardcore 3D game in which I would want the processor, I would do what I described above and just note to the end user for performance purposes run the game with no other applications in the background.

In a 2D game? Multimedia timer would be great.

Quote:

---

Originally Posted by JamesSchumacher

Actually, yes it does... That's what the SetPriorityClass() (I think that is the one) function is for. Setting the PROCESS PRIORITY.

---

Actually, this has nothing to do with my question. I asked whether you believe the OS schedules threads in an app with 9 worker threads differently than it schedules 10 separate single-threaded applications. Just to be clear all threads in all apps have normal priority.

Can you answer the question (without going into an irrelevant game discourse)?

Quote:

---

Originally Posted by Arjay

Actually, this has nothing to do with my question. I asked whether you believe the OS schedules threads in an app with 9 worker threads differently than it schedules 10 separate single-threaded applications. Just to be clear all threads in all apps have normal priority.

Can you answer the question (without going into an irrelevant game discourse)?

---

Technically speaking? They are arranged in pretty much the same manner. The data is stored in (what else) a priority queue. Which can be implemented as doubly linked list, or as a vector storing pointers to data structures.

BTW... The Windows thread scheduler uses TWO values to determine how often a thread gets a slice, and for how long.

Quote:

---

Originally Posted by JamesSchumacher

BTW... The Windows thread scheduler uses TWO values to determine how often a thread gets a slice, and for how long.

---

In reality the algorithm used to determine thread scheduling can change (and does change) between versions of the OS. It's much better not to make assumptions about exactly how the scheduler functions, but rather to code it up more of like "I don't know how long my thread time slice will be or whether I'll get the complete time slice". The idea to use the maximum amout of CPU available in order to achieve better accuracy is flawed because your thread can be preempted at anytime.

At any rate, since you haven't answered the question in the last couple of posts, it's unlikely I'm going to get a direct answer.

Quote:

---

Originally Posted by Arjay

In reality the algorithm used to determine thread scheduling can change (and does change) between versions of the OS. It's much better not to make assumptions about exactly how the scheduler functions, but rather to code it up more of like "I don't know how long my thread time slice will be or whether I'll get the complete time slice". The idea to use the maximum amout of CPU available in order to achieve better accuracy is flawed because your thread can be preempted at anytime.

At any rate, since you haven't answered the question in the last couple of posts, it's unlikely I'm going to get a direct answer.

---

Since I do not work for Microsoft on the OS team, I cannot tell you I can for certain. Does that make you happy?

And actually, achieving better accuracy in terms of checking the performance counter, I have actually indeed proven that I have made it more accurate in terms of when code is executed. My bench tests have proven that.

Look how many test I ran... In more than 90% of the cases my code executed 'on time' so to speak.

It seems as if Sleep() / Wait() functions assume the possibility of preemption or taking code execution time into account (the time slice).

And if my code can be preempted at any time, doesn't that prove it's the scheduler's design that gives your app less total cycles?

I rest my case.

On the other end of the stick, the OS recognizes a tighter 'loop' in which the performance counter is being queried... Does this not in fact prove that the design is NOT flawed?

I know my code can be preempted.

I do not think you realize how much time is actually used up in most applications.

A case in which you are compressing files in the background... The problem is actually the disk access time, that's the bottleneck. Disk access requires longer periods of time... AND... During task switches, the disk reader needs to move around if another app is accessing the hard drive.

It's a combination of things, it's not my application alone that's the problem.

Which is why I related to myself also writing functions that are alternatives to C runtime and STL. In case of the C runtime, they run faster. In the case of STL, run faster sometimes and ALWAYS smaller.

This is like the misconception that inline code will always run faster than out of line code. It's not true. In fact, I have found for functions that do more than just returning a value or doing more than a few operations... Putting the code into an 'out of line' function always nets a faster result than the inline one. EVEN in member functions.

Quote:

---

Originally Posted by JamesSchumacher

Since I do not work for Microsoft on the OS team, I cannot tell you I can for certain. Does that make you happy?

And actually, achieving better accuracy in terms of checking the performance counter, I have actually indeed proven that I have made it more accurate in terms of when code is executed. My bench tests have proven that.

Look how many test I ran... In more than 90% of the cases my code executed 'on time' so to speak.

It seems as if Sleep() / Wait() functions assume the possibility of preemption or taking code execution time into account (the time slice).

And if my code can be preempted at any time, doesn't that prove it's the scheduler's design that gives your app less total cycles?

I rest my case.

On the other end of the stick, the OS recognizes a tighter 'loop' in which the performance counter is being queried... Does this not in fact prove that the design is NOT flawed?

I know my code can be preempted.

I do not think you realize how much time is actually used up in most applications.

A case in which you are compressing files in the background... The problem is actually the disk access time, that's the bottleneck. Disk access requires longer periods of time... AND... During task switches, the disk reader needs to move around if another app is accessing the hard drive.

It's a combination of things, it's not my application alone that's the problem.

Which is why I related to myself also writing functions that are alternatives to C runtime and STL. In case of the C runtime, they run faster. In the case of STL, run faster sometimes and ALWAYS smaller.

This is like the misconception that inline code will always run faster than out of line code. It's not true. In fact, I have found for functions that do more than just returning a value or doing more than a few operations... Putting the code into an 'out of line' function always nets a faster result than the inline one. EVEN in member functions.

---

You are wasting your talent with this programming gig, what you need to do is to start a career as a Spin Doctor - your ability to avoid questions is astounding. :D

Quote:

---

Originally Posted by Arjay

You are wasting your talent with this programming gig, what you need to do is to start a career as a Spin Doctor - your ability to avoid questions is astounding. :D

---

I take that as an insult.

I think you kind of have that backwards, in the sense that you were querying a few things and acting as if I did not in prior posts mention what you were talking about.

Oh well... I think this thread is over with.

I am sure that Arjay did not mean it as an insult, but meerly a joke. Arjay is a nice guy, he wouldn't purposefully offend.

Concerning the thread...it seemed to me that its start was to boast, not ask for help.

Good luck with your work James. :thumb:

Quote:

---

Originally Posted by PeejAvery

I am sure that Arjay did not mean it as an insult, but meerly a joke. Arjay is a nice guy, he wouldn't purposefully offend.

Concerning the thread...it seemed to me that its start was to boast, not ask for help.

Good luck with your work James. :thumb:

---

Thanks...

Quote:

---

A case in which you are compressing files in the background... The problem is actually the disk access time, that's the bottleneck.

---

No. This is a myth. This is absolutely wrong on my computer (and actually, on all computers I've owned up to now).
When I compress a RAR file, my CPU is eaten at 100% and my disk is read at 500 kilobytes/s and written at 100 or 200 kilobytes/s. My disk can read or write 10 megabytes/s without problem.
Of course, the numbers I gave are only a sample. In practice it's variable. But, in all case, on my computer, disk accesses are NEVER the bootleneck for file compression.

You still don't understand why everything would become incredibely inaccurate and slow if every application of the system were using YOUR sleep instead of the system ::Sleep().
e.g. an inaccuracy equal to half of the average time slice, on a single core system, if one other application does the same thing than yours, and more if several applications do it.

There's a very simple guideline in the programming world (it also applies to the real world to some extent):
When you do something unusual, always ask the question:
What happens if somebody else or everybody else does the same thing?

Quote:

---

And actually, achieving better accuracy in terms of checking the performance counter, I have actually indeed proven that I have made it more accurate in terms of when code is executed. My bench tests have proven that.

---

On MY computer, I've tested the system ::Sleep() function, and found that its accuracy is one millisecond when the process has HIGH_PRIORITY_CLASS.
Why?
Because, when the sleep time is elapsed, Windows 98 SE, *immediately* ends the time slice of low priority threads in favor of the high priority thread.

The closest acceptable thing to your sleep function, would be to increase the thread priority only for the time of the sleep operation, and then, restore its normal priority.
It has the advantage of not spending system resources uselessly.

Disadvantage? Well, it hasn't an accuracy of 1 microsecond. But, for a game running at 100 or 200 fps, a one millisecond accuracy is sufficient.
Quake II uses timeGetTime() and is perfectly smooth on my computer. (The fact that it has a variable framerate increases its smoothness).