I'm wondering if there's a good way to cause the current thread to sleep using the hires timer. I've tried two ways, one using the traditional Thread.sleep() method, and another using Thread.yield() in a while loop, using the hires timer to break at the appropriate time.

While the second method gives much more precise sleep time, it causes my cpu to churn at 100% the whole time. The first method is much more friendly on the system resources (about 4% cpu), but I believe Thread.sleep() uses the same timing device as System.currentTimeMillis(), making the sleep time completely untrustworthy.

Here's some code I whipped up to do this test in case it isn't clear what I'm talking about. Anyone have any thoughts on this?

The only way to sleep using the hires timer is 100% cpu I'm afraid, but don't forget that it's just a reflection on the underlying OS's inability to schedule threads with microsecond precision that's the real problem, not Java as such. If you're running a game there's no harm in it using 100% CPU anyway.

> If you're running a game there's no harm in it using 100% > CPU anyway.

Besides, 100% CPU usage is a psychological thing anyway. Back in the days of DOS, the CPU ran at 100% just to blink the cursor. All it means is that the program is using every cycle that's available to it. Unless it's running at a realtime priority, those cycles can (and will) go to other programs that need it.

It's people like you that make me glad I own a multi-processor machine. It's a good thing that you stick to one thread too, since otherwise you'd eat up all my cpu.

<sarcasm>I mean, holy crap, why would anybody ever want to play some mp3s, copy some files, burn a cd, or download the 500M demo of the latest game in the background?</sarcasm>

In my case, I also run a web server and a database server on the same machine I game on. I'm just too cheap ass to pay an additional $1000 for an entirely separate machine to dedicate to gaming.

Generally speaking, using 100% cpu is a sign of a poorly written application. Btw, using Thread.yield() is no more safe than using Thread.sleep(), because your thread scheduler gives no guarantees about the amount of time that elapses between when the thread yields and when it gets its next time slice.

Any os that can't handle a small number of threads well simply has a very poor thread scheduler.

Oh, quit your whining.Have you ever bothered to check how much CPU Quake 3 uses? Didn't think so. And if you'd *read* what I said, you'd realize that using 100% CPU doesn't stop those other programs from getting the same amount of CPU they'd get if they if your program *wasn't* running at 100%.

No, I don't play Quake3 (I don't like FPS's), yet I know how much CPU the games I do run take, and it sure isn't 100%. (Gosh darn - that's probably because they don't just throw CPU cycles away in dead spins).

Spinning on Thread.yield() does nothing but waste CPU cycles, because you are constantly invoking the thread scheduler. Your program immediately goes back on the ready queue, and must be invoked by the thread scheduler again, just to put itself right back onto the queue. You are constantly thrashing registers, etc... because the os must perform a full context switch (and in the case of a single-threaded program - a full process context switch) each time your thread is rescheduled. (Which, at 1GHZ, may easily be several thousand times a second, even with several other programs running).

I hope you don't write software in real life, JBanes, because you obviously don't know what you're talking about.

> yet I know how much CPU the games I do run take, and it sure isn't 100%.

Then you would be wrong my friend. :-) Ok, that's only partially correct. If you are VSynced, there is some sleep time from the process blocking. If you aren't (very common), then you use 100%.

> Spinning on Thread.yield() does nothing but waste CPU cycles, because you are constantly invoking the thread scheduler

It does waste *some* CPU. I wouldn't really worry about it tho. Your CPU spends approximately 90% of its time doing absolutely zilch. Most of the *real* time is spent waiting for I/O from the memory bus or AGP bus. It won't kill your processor to do a little register swapping for a millisecond or two.

> (and in the case of a single-threaded program - a full process context switch) each time your thread is rescheduled.

This is a *good* thing. It means that Database or 500 meg download you've got running in the background is going to get the CPU time it deserves, because you don't need it! Imagine that. Oh, and if you're trying to burn a CD while playing a video game, I hope you have a burn proof drive.

> (Which, at 1GHZ, may easily be several thousand times a second, even with several other programs running).

Pretty neat, isn't it? We're actually making the OS *do* something with those millions of cycles instead of just sleeping like a lazy bear.

In all seriousness, the best solution would be (as Cas stated) a sub millisecond scheduler. Since we don't have that, we'll have to deal with what we've got.

> I hope you don't write software in real life, JBanes, because you obviously don't know what you're talking about.

<sarcasm>Ooo... Good one! That's the way to show me. </sarcasm>

> God bless,

You know, this seems a bit out of place. You did after all post an inflammatory message in reply to a highly respected member of this community (Cas, not me. I hope I'm highly respected, but I'm not immodest enough to assume. :-)). Oh well. I'm certainly turning the other cheek here.

Okay. This is just plain ridiculous. There's not much I can say against wild assertions like this.

Even pretending that every game I run only sleeps during vsync, vsync itself is an intelligent way of blocking a thread. When you vsync, your program *blocks* until it can blit a frame. It doesn't sit spinning in a thread-yielding loop, sucking up all of your CPU cycles.

Most of the *real* time is spent waiting for I/O from the memory bus or AGP bus.

This would only be true if the game I was running was the sole process executing on my machine - but that's kind of the whole point of our ongoing discussion here, isn't it? As an example, pretend I'm running a program to find the next prime number.

This is a *good* thing.

No, it is not a *good* thing. Spurious context switches are an absolute *waste* of processor time. When a game determines that it doesn't need 200 milliseconds of processing time, it should not be constantly adding itself back to the scheduler every 100th of a millisecond.

If you're interested in books, papers, newsgroups, etc... on the topic, just ask.

Pretty neat, isn't it? We're actually making the OS *do* something with those millions of cycles instead of just sleeping like a lazy bear.

No, what you're making the OS do is handle several thousands of spurious useless context switches a second. Not what I'd call a meaningful use of cpu time. Rather than neat - I'd call that dumb.

In all seriousness, the best solution would be (as Cas stated) a sub millisecond scheduler. Since we don't have that, we'll have to deal with what we've got.

That would depend upon your target platform wouldn't it? It seems that would be why the Java API actually provides a nano-second resolution API.

You know, this seems a bit out of place. You did after all post an inflammatory message in reply to a highly respected member of this community

Inflammatory, because I would like to actually use my processor for something else besides context switching? Can nobody dispute Cas? Cas may be the god of video games (he makes a mean AF, but I'm not convinced yet), but that doesn't mean he's an expert in computer architecture and operating systems.

You know, this seems a bit out of place. You did after all post an inflammatory message in reply to a highly respected member of this community (Cas, not me. I hope I'm highly respected, but I'm not immodest enough to assume. ).

I've just got to respond directly to this. I can't believe that I'm being the one called "inflammatory". I say that a well written game shouldn't take my machine down, and you tell me to "quit whining"... Who's being inflammatory, here?

Oh well. I'm certainly turning the other cheek here.

If you read the same Bible I do, then you'll know that the two greatest commandments are

but I believe Thread.sleep() uses the same timing device as System.currentTimeMillis(), making the sleep time completely untrustworthy

This depends upon your platform, but, definitely, for at least many versions of Windows, the timer tied to System.currentTimeMillis() is nowhere near as accurate as the internal timer used by the thread scheduler. You'll also probably see much better behavior on a non-DOS operating system like Windows 2000.

IIRC, a long time ago, someone posted some code on JavaGaming.org for a timer that was much more accurate based on the thread scheduler, then one based on System.currentTimeMillis(). I don't remember the relevant platforms at the moment.

Based on your initial reaction, I'd say you might want to review the second.

The Bible also says:

He who keeps his mouth and his tongue keeps himself out of trouble.

as well as

He who rebukes a man will afterward find more favor than he who flatters with his tongue.

Your response to Cas was unprofessional. Plain and simple. Should you not have been rebuked for it? Or are you going to argue that implying (without any evidence) that good, helpful people are incompetent idiots isn't inflammatory? Any of us would be happy to have an intelligent debate. It does however, require that we act like intelligent people.

I'm sorry to drag religion into this, but it just doesn't seem right for someone to profess to be a Christian (or is it Jewish? No matter.) and yet attack one of his neighbors at random.

Okay. This is just plain ridiculous. There's not much I can say against wild assertions like this.

You said yourself that you hadn't checked. I have. Games will take all the CPU available to them if they can. You can check for yourself sometime. VSyncing is usually the only block point in games.

When a game determines that it doesn't need 200 milliseconds of processing time,

This is a contrived example. The only reason for yielding a thread instead of sleeping is for the purpose of sub-millisecond accuracy. If you're going to sleep for 200 ms, you are not writing time critical code.

If you're interested in books, papers, newsgroups, etc... on the topic, just ask.

No thanks, I've read them. On the other hand, if you'd be interested in real world experimentation and results, I'd be happy to share my findings. They're complete enough to where I wrote an entire timing library around them.

This depends upon your platform, but, definitely, for at least many versions of Windows, the timer tied to System.currentTimeMillis() is nowhere near as accurate as the internal timer used by the thread scheduler. You'll also probably see much better behavior on a non-DOS operating system like Windows 2000.

I used Windows 2000 as one of my testing platforms. Its ability to time is poor. Unixes are better. MacOSX is probably the best consumer OS for timing.

That would depend upon your target platform wouldn't it? It seems that would be why the Java API actually provides a nano-second resolution API.

I'm not sure about OSX, but no other consumer OS (i.e. Gaming target) has a sub-millisecond task scheduler. In fact, the Java sources explicitly change any nanosecond request into an extra millisecond.

IIRC, a long time ago, someone posted some code on JavaGaming.org for a timer that was much more accurate based on the thread scheduler, then one based on System.currentTimeMillis(). I don't remember the relevant platforms at the moment.

The relevant platform was Windows. And it did not produce sub-millisecond timing. It merely provided an approximate timing with a potential drift of 1 to 2 milliseconds for every tick. The reason for its existence is that Win9x platforms are only accurate to 50ms, while the NT line of platforms are only accurate to 10ms. For more info, look up my dissertation on a new Timing algorithm in the Shared Code section.

This would only be true if the game I was running was the sole process executing on my machine - but that's kind of the whole point of our ongoing discussion here, isn't it?

It is *not* true. CPUs are anywhere from a hundred to a thousand fold faster than the memory subsystems that service them. They can (and will) sit in a wait states while that information arrives. Consumer hardware relies heavily on caches to decrease the wait time. Swapping some registers is such a small amount of data that it will most certainly operate out of cache if possible. Of course, the only way to know the real world performance characteristics for sure is to profile!

As an example, pretend I'm running a program to find the next prime number.

It seems silly to run such a processor intensive app while you're trying to play a video game, but I'll bite. The program will get near the same amount of CPU time using yields as it would get if the game used sleeps. Why? Because it's asking for full CPU time as well. That means it will keep running until the scheduler pre-empts it and gives some time to our game which (wait for it) yields its time back to the prime number generator! Cool, huh?

You do want a game to run as close as possible to the refresh rate. If it only takes 50% cpu to do that, then the game should only use up 50% of the cpu.

And how are you going to do that without accurate timing?

Can nobody dispute Cas? Cas may be the god of video games (he makes a mean AF, but I'm not convinced yet), but that doesn't mean he's an expert in computer architecture and operating systems.

For the record, Cas is as human as you or I. That doesn't mean he deserves to be attacked for stating his educated opinion.

As I see it, you have two choices from here. You can have the humility to calm down and have an intelligent discussion (most welcomed) or you can continue an attack. If you're going to do the later, please use the private message feature. The rest of JGO doesn't need to be subjected to a flame war.

JBanes, I never used the words "incompetent idiot" nor any words that could begin to be misconstrued as synonyms for such. I'm disappointed that you've sunk to putting such words in my mouth.

I'm sorry to drag religion into this...

Now you're just making me angry. Insinuating that I attacked anybody is ridiculous. It's sad to see you drop down to ad-hominem attacks as opposed to examining the facts at hand.

You said yourself that you hadn't checked...

No, I said I had checked with the games _I_ play - not Quake3 which just makes me sick, thank you very much. Since you're ignoring what I have to say on this, it seems that my only recourse is to ignore you.

This is a contrived example.

Ummm... no. If you're driving a particular frame rate, you can easily have left over processing time that you know you don't need. That's not contrived at all. Considering that I've written medical imaging software (video in particular - cardiograms, angiograms, ultrasounds, etc...), based on that requirement, I hardly find it contrived.

No thanks, I've read them.

Lol. It's impressive that you've managed to read all of the material available on the subject. I'll have to tell Dave Butenhof that you should be invited for inclusion in the posix threads committee, being the expert that you are. Perhaps Doug Lea would like to take some pointers from you?

On the other hand, if you'd be interested in real world experimentation and results, I'd be happy to share my findings.

As I said, I've already written production, "time-sensitive", graphical applications. I'd say that that qualifies as better than "experimentation". Unlike what Cas preaches, this software was also multi-threaded, which resulted in nearly a 100% performance gain (on dual processor machines). Am I attacking Cas's character? No. Am I saying that I have direct experience that contradicts his advice concerning multi-threaded programs? Yes.

I used Windows 2000 as one of my testing platforms. Its ability to time is poor. Unixes are better. MacOSX is probably the best consumer OS for timing.

You can time as fast as your processor ticks in Windows - QueryPerformanceCounter() - AFAIK, any decent OS will let you do the same.

I'm not sure about OSX, but no other consumer OS (i.e. Gaming target) has a sub-millisecond task scheduler. In fact, the Java sources explicitly change any nanosecond request into an extra millisecond.

I'd be glad to look at any documentation you can give me that supports your statements for the respective operating systems. OS/2, almost a decade ago, had a scheduler that would do at least millisecond timing. That was on machines that were measured in the ones of megahertz - not gigahertz.

As far as the Java API goes, it doesn't really make any difference whether the API supports sub-millisecond or not. The JVM threads are scheduled by the system scheduler, and thus they will be scheduled at whatever resolution the os scheduler natively uses. No, you won't be able to actually specify scheduling at nanoseconds, but you don't need to do it either.

It is *not* true.

Look, I've already given you a simple example of a compute bound process. You can call it stupid all you want (why would somebody ever want to compress their video to MPEG4 and play a game simultaneously?) and you can dance around it all you want, but all you're really doing is just ignoring the facts.

The program will get near the same amount of CPU time using yields as it would get if the game used sleeps. Why? Because it's asking for full CPU time as well.

You just don't get it, do you? Imagine your scheduler is running at 1/10th millisecond intervals (which seems awfully latent to me, but I'll be generous), and your gaming app knows it doesn't need to do anything for the next 20 milliseconds. Your program will be rescheduled and executed 200 times in those 20 milliseconds, just because you didn't specify a wait period of 20 milliseconds.

Sounds like a case of jealousy to me.

Now you're accusing me of being jealous, because I say that gaming experience doesn't directly translate to computer architecture and operating systems? Lol. Will the ridiculousness never end? I can't do anything but sit back and laugh at that.

I would suggest...

I'd suggest you get a grip and calmly examine the facts at hand.

For the record, Cas is as human as you or I. That doesn't mean he deserves to be attacked for stating his educated opinion.

I've said it before, and this is the last time I'll say it. I did not attack Cas. I said that I disdane programs that eat up 100% of my CPU with spinning wait loops.

As I see it, you have two choices from here.

I think you're the one who needs to calm down JBanes. You've been the attacker, not me. Not once did I ever make a single statement about Cas' character. I regret even engaging you concerning your statements about my character.

Let me know when you're willing to discuss this like a rational human being.

It's worth bringing a tiny bit of sanity back to the bible-hurling* and flames and such to mention:

- thou shalt only use the hires timer to sleep when you can't get WGL_EXT_swap_interval- if you do a spin on Thread.yield() you will find that you are in fact not preempting any other threads and that things run as smoothly as might be expected whilst trying to play a high performance video game

Cas

* as an interesting aside, I wasn't aware that the 10 commandments had been assigned priorities. I'll put them in my conscience scheduler and spin on SecondComing.yield() until something happens.

> as an interesting aside, I wasn't aware that the 10 > commandments had been assigned priorities. I'll put them > in my conscience scheduler and spin on > SecondComing.yield() until something happens.

In fact they do! See those tiny numbers next to the verse? Those are Unix priorities! That would make the highest prioirity "Thou shalt have no other gods before me." with a whopping high priority of 2! Guess God didn't want to strain your mental processor with negative prioities. Besides, that would have required root access which would be a big secuirty vulnerability.

Toby, you say that you never attacked anyone, yet your words say otherwise. The only conclusion I can come to then, is that you don't realize how your words are seen by others. Let me show you something:

Your words: It's people like you that make me glad I own a multi-processor machine.

I don't know where you come from, but this sentence is packed with insinuation. Try this:

I'm not sure if I agree with Cas here. I've done video for medical research programs without needing to use yields.

Your words: <sarcasm>I mean, holy crap, why would anybody ever want to play some mp3s, copy some files, burn a cd, or download the 500M demo of the latest game in the background?</sarcasm>

Now compare that with this:

If you are using 100% of the processor, won't that interfere with background processes such as downloading files or running database and web servers?

You really do owe Cas an apology. As for my "quit your whining", I heard that myself growing up and I'm thankful for that. (Kept me in line.) I'm sorry if you find that offensive.

Now for your arguments. I'm afraid that I will no longer discuss them here. This board has seen enough harsh words. To continue would only stray from the topic. I again invite you to use the private message feature if you wish to continue. We can then return to the main forum later as civilized individuals.

- thou shalt only use the hires timer to sleep when you can't get WGL_EXT_swap_interval

(Well, assuming you're on a Windows platform anyway) Yes, this brings back a little sanity - What would be best is that the game lets you even specify a frame rate / refresh rate to use. Many do so.

- if you do a spin on Thread.yield() you will find that you are in fact not preempting any other threads and that things run as smoothly as might be expected whilst trying to play a high performance video game

I never said that Thread.yield() would pre-empt other threads. I said that Thread.yield() would waste useless cycles as your application is constantly rescheduled. Compare to a wait() with a meaningful sleep time which would keep your app off the runnable queue until the time elapsed. (Why do I have to keep repeating this over and over?)

as an interesting aside, I wasn't aware that the 10 commandments had been assigned priorities.

Well, I guess you learn something new every day. It comes directly from Christ's mouth - Matthew 22:36-40 (NIV):

"Teacher, which is the greatest commandment in the Law?" Jesus replied: "Love the Lord your God with all your heart and with all your soul and with all your mind. This is the first and greatest commandment. And the second is like it: "Love your neighbor as yourself. All the Law and the Prophets hang on these two commandments."

You know you've lost an argument when you bring God in to fight it for you.

This is going to turn into a holy war no matter how you spin it, because it boils down to one question, how important are CPU cycles to you? Which depends on the application, I'm of the camp, use all that you get, and Jesus will back me up on that!

Basically, you both could be right and you both could be wrong. The answer is... it depends. So shut up and move on.

The only conclusion I can come to then, is that you don't realize how your words are seen by others.

That seems to be the likely case.

Your words

What insinuation? Saying that I don't like spin-loops needlessly eating up my precious cpu cycles? That's what I see there. It's more than an insinuation, it's out right blatant - as I intended it to be. Perhaps instead of "people like you", I should have said "statements like that".

Your words

I find that sarcasm is often an effective means to convey a point across, just like exaggeration of a point to ludicrousness. I try to use the "<sarcasm>" tag to cue people in to my intent. (Seeing as how text is a poor medium for that).

Try this:

I know I don't agree with Cas. I'd be lying if I pretended I didn't.

Now compare that with this:

I'm not interested in asking that question - rather my goal was to state a more correct fact.

You really do owe Cas an apology.

I don't think so - Like I said before, I never intended to attack his character - only his advice. I'm sorry if you or he find that offensive, but that has always been "fair game" in my book. (Attack someone's methods, not their person).

As for my "quit your whining", I heard that myself growing up and I'm thankful for that. (Kept me in line.) I'm sorry if you find that offensive.

Yep. That's offensive. You've stated nothing of fact, and you've disparaged my character. That pretty much sums up half of what you've written in this thread.

Now for your arguments. I'm afraid that I will no longer discuss them here. This board has seen enough harsh words. To continue would only stray from the topic. I again invite you to use the private message feature if you wish to continue. We can then return to the main forum later as civilized individuals.

Discussion usually stays civilized when you stick to the facts. That's always been my goal. I'll try to make an effort to guard against inflammatory language.

You know you've lost an argument when you bring God in to fight it for you.

Well, considering that JBanes first stated that he was certainly turning the other cheek and quoted Matthew 5:39, a Bible verse about "turning the other cheek", (which you can't see now, because he has since changed his signature), I guess it's pretty safe to conclude who felt it necessary draw attention away from the facts.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org