I am using CreateProcess function to create a process which is a chess engine (uses UCI protocol). I can't set in it's code any Sleep commands, because it's not mine. Is there any way to set upper bound of cpu usage (for example 90 %) for it, because it uses all 100 %?
All you can do it lower its priority and what cores it runs at. If you have a dual core and it eats both cores, then banning it to use one care will cut percentage in half.
Lowering priority doesn't mean it will drop its cpu usage per se, but it means other processes may use the cpu before that process.
Either way, changing priority and processor affinity (what cores it runs on) may have impacts on the code, so test it properly before setting it permanently.
Oh, and for future reference, anything having to do with Windows APIs or the like (not related to the actual language) should go in the Windows programming section, regardless of language used.
Originally Posted by Adak
Why would you want it to use less than 100% of the CPU capacity?
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Chess AI is a very CPU intensive algorithm, requiring evaluation of a huge number of plays to find a good move.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Who cares if it uses 100%? That number is arrived at internally by Windows and is essentially saying your program is hogging the CPU time slices. But if it is a game or something intensive like AI then who cares? Now if it is a Windows Forms app or a WPF app or some program that spends most of its time waiting for user input before it does anything meaningful then that is another story.
You see this same thread repeated ad infinitum on game forums everywhere. Why does my game use 100% CPU, yada yada yada......
Last edited by VirtualAce; 07-25-2012 at 05:38 PM.
I, for one, cares when an application--or game--hogs the CPU for no reason, when there is no need.
(Obviously, if the game is running intensive AI and stuff, then it's okay--it's performing legitimate work.)
I only care when it is an application. I could care less about games. If the game is rendering 60 to 100 FPS then it can hog whatever it wants however it wants in my opinion so long as my game is fast and silky smooth. If I wanted to efficiently run Word, IM, Outlook, etc. then I wouldn't be playing a game. That makes as much sense as complaining about lag in an online game while you are downloading a game from Steam.I, for one, cares when an application--or game--hogs the CPU for no reason, when there is no need.
No, it doesn't. Power means energy. Wasted cpu cycles is wasted energy and heat.
Are you fine with applications hogging 100% cpu using idle priority? That's the same thing. It won't harm multi-tasking, but unless it's doing something useful with those cycles, it's a waste of energy.
Do you understand the difference between Peek and Get message pumps? (and so can make an informed choice which to use when designing a program.)
This difference in msg pumps means that the game does not sit idle waiting for input like an app.
The 'something useful' the game is doing with the CPU cycles is updating the position of objects based on time and rendering these changes to the screen.
Some real-time systems apps use this time to poll external devices (SCADA, multiports, etc) for data/state changes.
Generally...
An app uses GetMessage() which only returns to the app when there is a message to process (ie it monitors the OS msg queue waiting until a msg for the app appears). This 'waiting' takes no CPU cycles (that are assigned to the apps process).
A game uses PeekMessage() which check if there is a msg and it returns even if there is no msg for the process. This allows the game to perform required tasks while there is no (user) input (ie update position of objects based on time, redraw screen, etc then check again for input, rinse and repeat).
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
Yes, I'm aware of the differences, though I will most likely not create a Pure Win32 in any distant future.
I'm no expert on games, either, so knowing exactly how they are typically coded are beyond me. Nevertheless, I find wasting cpu cycles with idle looping ... well, a waste. There should be better ways of coding it (might not be easy, but that's another matter).
I have a sneaking suspicion that you brought up idle looping specifically. There is a chance that an application is doing an incredible amount of work. F@h for example can donate 100% cpu cycles to a good cause. You can say "I told you so" when we see the code....
I did specifically mention that I don't like wasted cpu cycles used for no good work (eg idle loop).
If those cycles are put to good use (eg rendering, AIs, collision handling, etc), then they are not wasted.
I simply objected to the notion that it's okay for any game to use all the cpu (ie, don't blindly trust them).
Then your statement about games is incorrect even by your standards. If a game is taking cycles it is putting them to good use.If those cycles are put to good use (eg rendering, AIs, collision handling, etc), then they are not wasted.
Do truly all games do that? A lot of them could be spending lots of time in an idle loop, because from what I hear, they are pretty typical in games.
All I am implying is that just because it is a game, it should not be freed from suspicion. It is not excluded from suspicion by definition or something just because it's a game. It is, after all, an application, though of a different sort. It could be a poorly coded game, just as an application can be poorly coded.
Last edited by Elysia; 07-26-2012 at 05:35 PM.
There is no such thing as an idle loop in most games. Games update the world in real time which means something is being processed at all times in the background. Hardly any games sit and wait for user input. Games are double buffered and Windows apps are usually not double buffered or at least in the same way. In Windows you can draw the screen once and forget about it until something changes. In Direct3D and OGL if you don't render it...it isn't there. In other words you must render the screen regardless if the user pressed any keys, any events happened, etc. So even if you are sitting waiting to snipe someone on your fav FPS even though there is no input from you it is updating reams of data in the background and at the very least is rendering your scene. Not all of the rendering pipeline is offloaded to the GPU. There are still transformations and calculations happening in software at all times. If there are any scripts running those must be continuously updated as well. I can assure you that unless you are playing Minesweeper or Solitaire that most of your games that appear to be idle are far from it.
Note that if the game stopped these calculations to wait for your input your character would fall through the world, you would be kicked from the server for inactivity or failure to report within a set amount of time, etc., etc. Most game programmers have the notion that if you are running their game then your system is theirs. They will do everything they can to make the gameplay smooth and fluid and if that means consuming every last free resource your system has...well so be it....you decided to play their game.
You must have this mindset when programming games professionally. Imagine the person out there that went out and bought tons of RAM just so your game will run better on his system. However much to their chagrin b/c you didn't try to allocate and use more memory when it was available so your game runs exactly the same as it does on a system with less RAM. That will work for consoles where there is a static hardware environment but it will make PC gamers quite angry. The same is true for video cards and other hardware. Gamers want performance and they pay pretty pennies to get it. Your new game best try to utilize every aspect of it or you won't be in business long. On the same note though your game should run quite well with the posted lowest specs. So what is interesting about the environment is that when the power is there you should be using it and when it is not you better figure out how to squeeze more out of less.
Last edited by VirtualAce; 07-26-2012 at 05:48 PM.
