An accurate form of Sleep()?

[JamesSchumacher]

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.

[Arjay]

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.

[JamesSchumacher]

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.

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.

[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.

[JamesSchumacher]

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.

Thanks...

[SuperKoko]

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?

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).