Here is why the above post is -3.

• Battery life is not your only concern, so just because something plugs into a wall does not mean there is no other possible reason not to want to reduce the CPU load.
  
  • If your PC is burning cycles needlessly it runs hot.  This can cause your fans to overwork themselves and eventually shut down, allowing the CPU to overheat, possibly causing permanent damage.  Though a main loop in itself is unlikely to cause this.
  • If your PC is burning cycles needlessly it costs money.  A sleeping PC < a normal-use PC < a dedicated Battlefield 3 PC in terms of daily expenses to your electricity bill.
  • There are other applications running besides your game (and its main loop).  If your main loop takes 99% of your CPU, other applications starve.  You won’t get that ever-so-important Google Talk message notification until hours later when the game shuts down.
• If your target device has a battery, you need to give time back to the operating system as much as you can so that it can conserve that battery.
  
  • Your loop isn’t run when it’s run.  It is run when you tell it to run.  For iOS this generally means a setting on the display link to trigger at, say, 30 FPS.  This conserves battery life, whereas telling it to trigger 60 times per second wastes it.

L. Spiro

While I agree with the sentiment of your post, there are several factual inaccuracies present that need to be addressed:

1. If your fans are spinning up when you run a while(true); then you have a serious problem. That is not to say that you should run such a loop, but the idea that 100% CPU usage is going to overheat and melt your machine is ludicrous. That may have been true a long time ago, on hardware from the 1980s, but if your machine is melting down on a while(true); loop you've got a lot bigger issues than said loop.

2. Windows (and in fact pretty much every operating system you will find on PC class hardware) is a pre-emptive multitasking operating system. This means every single thread is allocated a slice of the CPU's time and when that slice of time is up it is preempted and another thread scheduled. All processes, in Windows, will get their own slice of time and a chance to do their work. If it were otherwise then your game would be unable to render, as all of the actual work happens during the driver/kernel's time slice. You can resource starve threads, but that's an issue for your own process and not for other processes that are running concurrently, and if you screw around with thread priorities you can increase your timeslice, but usually only to your own detriment (if you starve the kernel's threads... most of the work you schedule just doesn't get done).

3. While a sleeping PC certainly costs less to run an a running PC, a "Battlefield 3 PC" might cost less to run than a "normal" PC. Why? Because the power supply that you would put in such a machine (say 1000w) is actually much more efficient than what you will find in your typical Dell. An example: My PC, which was a powerful beast when I built it, was recently upgraded to an even more powerful set of hardware. However, during general usage its power usage DROPPED (traced by my UPS, which feeds information and usage stats back to the machine) on average. This is because the power supply, amongst other things, is much more efficient at its job.

Now, on to CPU usage and your game loop:
In general, if you are done with your timeslice you should probably wait (using one of those efficient timing mechanisms that are not sleep) for the appropriate amount of time so that you can wake up and get going again shortly. Sleep does more than simply tell your thread to "wait for N seconds (or milliseconds)", it surrenders your timeslice entirely, and when you get scheduled again is entirely up in the air. In otherwords, sleep simply tells the operating system to schedule your thread anytime AFTER the amount of time you indicate. When that "after" is is entirely unspecified. You can also use features such as v-sync to allow the system to surrender your timeslice when you call present, etc. This allows you to defer the choice to the end user, as you can provide options to disable v-sync thus allowing them to consume more power (for likely little gain).

Windows includes high performance waitable timers, which are usually far more than sufficient for the needs of a simple game loop that needs to run N times a second.

On mobile hardware this is a harder problem, because many mobile platforms dont' expose such timers, or the hardware doesn't necessarily support it. However the typical "energy efficient" mechanisms I've seen typically involve a scheduled timer that goes off which triggers rendering events, etc. or mechanisms that involve getting notified when the screen is going to update and taking appropriate actions then (for rendering). These kinds of mechanisms allow the hardware, and operating system, to take advantage of the ability to dynamically power on and off various components in order to conserve and extend battery life. In fact, many of the modern mobile processors support the ability to power off components OF the CPU in order to enable them to achieve even greater energy savings, thus extending battery life.

Here is why the above post is -3.

• Battery life is not your only concern, so just because something plugs into a wall does not mean there is no other possible reason not to want to reduce the CPU load.
  
  • If your PC is burning cycles needlessly it runs hot.  This can cause your fans to overwork themselves and eventually shut down, allowing the CPU to overheat, possibly causing permanent damage.  Though a main loop in itself is unlikely to cause this.
  • If your PC is burning cycles needlessly it costs money.  A sleeping PC < a normal-use PC < a dedicated Battlefield 3 PC in terms of daily expenses to your electricity bill.
  • There are other applications running besides your game (and its main loop).  If your main loop takes 99% of your CPU, other applications starve.  You won’t get that ever-so-important Google Talk message notification until hours later when the game shuts down.
• If your target device has a battery, you need to give time back to the operating system as much as you can so that it can conserve that battery.
  
  • Your loop isn’t run when it’s run.  It is run when you tell it to run.  For iOS this generally means a setting on the display link to trigger at, say, 30 FPS.  This conserves battery life, whereas telling it to trigger 60 times per second wastes it.

L. Spiro

While I agree with the sentiment of your post, there are several factual inaccuracies present that need to be addressed:

1. If your fans are spinning up when you run a while(true); then you have a serious problem. That is not to say that you should run such a loop, but the idea that 100% CPU usage is going to overheat and melt your machine is ludicrous. That may have been true a long time ago, on hardware from the 1980s, but if your machine is melting down on a while(true); loop you've got a lot bigger issues than said loop.

2. Windows (and in fact pretty much every operating system you will find on PC class hardware) is a pre-emptive multitasking operating system. This means every single thread is allocated a slice of the CPU's time and when that slice of time is up it is preempted and another thread scheduled. All processes, in Windows, will get their own slice of time and a chance to do their work. If it were otherwise then your game would be unable to render, as all of the actual work happens during the driver/kernel's time slice. You can resource starve threads, but that's an issue for your own process and not for other processes that are running concurrently, and if you screw around with thread priorities you can increase your timeslice, but usually only to your own detriment (if you starve the kernel's threads... most of the work you schedule just doesn't get done).

3. While a sleeping PC certainly costs less to run an a running PC, a "Battlefield 3 PC" might cost less to run than a "normal" PC. Why? Because the power supply that you would put in such a machine (say 1000w) is actually much more efficient than what you will find in your typical Dell. An example: My PC, which was a powerful beast when I built it, was recently upgraded to an even more powerful set of hardware. However, during general usage its power usage DROPPED (traced by my UPS, which feeds information and usage stats back to the machine) on average. This is because the power supply, amongst other things, is much more efficient at its job.

Now, on to CPU usage and your game loop:
In general, if you are done with your timeslice you should probably wait (using one of those efficient timing mechanisms that are not sleep) for the appropriate amount of time so that you can wake up and get going again shortly. Sleep does more than simply tell your thread to "wait for N seconds (or milliseconds)", it surrenders your timeslice entirely, and when you get scheduled again is entirely up in the air. In otherwords, sleep simply tells the operating system to schedule your thread anytime AFTER the amount of time you indicate. When that "after" is is entirely unspecified.

That is not to say that a non-waiting loop is necessarily a bad thing, if your game is doing sufficient work per frame, it may not have much time left over to "sleep" for at all, but this often is not an issue except in AAA games.

Windows includes high performance waitable timers, which are usually far more than sufficient for the needs of a simple game loop that needs to run N times a second.

On mobile hardware this is a harder problem, because many mobile platforms dont' expose such timers, or the hardware doesn't necessarily support it. However the typical "energy efficient" mechanisms I've seen typically involve a scheduled timer that goes off which triggers rendering events, etc. or mechanisms that involve getting notified when the screen is going to update and taking appropriate actions then (for rendering). These kinds of mechanisms allow the hardware, and operating system, to take advantage of the ability to dynamically power on and off various components in order to conserve and extend battery life. In fact, many of the modern mobile processors support the ability to power off components OF the CPU in order to enable them to achieve even greater energy savings, thus extending battery life.

Here is why the above post is -3.

• Battery life is not your only concern, so just because something plugs into a wall does not mean there is no other possible reason not to want to reduce the CPU load.
  
  • If your PC is burning cycles needlessly it runs hot.  This can cause your fans to overwork themselves and eventually shut down, allowing the CPU to overheat, possibly causing permanent damage.  Though a main loop in itself is unlikely to cause this.
  • If your PC is burning cycles needlessly it costs money.  A sleeping PC < a normal-use PC < a dedicated Battlefield 3 PC in terms of daily expenses to your electricity bill.
  • There are other applications running besides your game (and its main loop).  If your main loop takes 99% of your CPU, other applications starve.  You won’t get that ever-so-important Google Talk message notification until hours later when the game shuts down.
• If your target device has a battery, you need to give time back to the operating system as much as you can so that it can conserve that battery.
  
  • Your loop isn’t run when it’s run.  It is run when you tell it to run.  For iOS this generally means a setting on the display link to trigger at, say, 30 FPS.  This conserves battery life, whereas telling it to trigger 60 times per second wastes it.

L. Spiro

While I agree with the sentiment of your post, there are several factual inaccuracies present that need to be addressed:

1. If your fans are spinning up when you run a while(true); then you have a serious problem. That is not to say that you should run such a loop, but the idea that 100% CPU usage is going to overheat and melt your machine is ludicrous. That may have been true a long time ago, on hardware from the 1980s, but if your machine is melting down on a while(true); loop you've got a lot bigger issues than said loop.
2. Windows (and in fact pretty much every operating system you will find on PC class hardware) is a pre-emptive multitasking operating system. This means every single thread is allocated a slice of the CPU's time and when that slice of time is up it is preempted and another thread scheduled. All processes, in Windows, will get their own slice of time and a chance to do their work. If it were otherwise then your game would be unable to render, as all of the actual work happens during the driver/kernel's time slice.
3. While a sleeping PC certainly costs less to run an a running PC, a "Battlefield 3 PC" might cost less to run than a "normal" PC. Why? Because the power supply that you would put in such a machine (say 1000w) is actually much more efficient than what you will find in your typical Dell. An example: My PC, which was a powerful beast when I built it, was recently upgraded to an even more powerful set of hardware. However, during general usage its power usage DROPPED (traced by my UPS, which feeds information and usage stats back to the machine) on average. This is because the power supply, amongst other things, is much more efficient at its job.

Now, on to CPU usage and your game loop:
In general, if you are done with your timeslice you should probably wait (using one of those efficient timing mechanisms that are not sleep) for the appropriate amount of time so that you can wake up and get going again shortly. Sleep does more than simply tell your thread to "wait for N seconds (or milliseconds)", it surrenders your timeslice entirely, and when you get scheduled again is entirely up in the air. In otherwords, sleep simply tells the operating system to schedule your thread anytime AFTER the amount of time you indicate. When that "after" is is entirely unspecified.

That is not to say that a non-waiting loop is necessarily a bad thing, if your game is doing sufficient work per frame, it may not have much time left over to "sleep" for at all, but this often is not an issue except in AAA games.

Windows includes high performance waitable timers, which are usually far more than sufficient for the needs of a simple game loop that needs to run N times a second.

On mobile hardware this is a harder problem, because many mobile platforms dont' expose such timers, or the hardware doesn't necessarily support it. However the typical "energy efficient" mechanisms I've seen typically involve a scheduled timer that goes off which triggers rendering events, etc. or mechanisms that involve getting notified when the screen is going to update and taking appropriate actions then (for rendering). These kinds of mechanisms allow the hardware, and operating system, to take advantage of the ability to dynamically power on and off various components in order to conserve and extend battery life. In fact, many of the modern mobile processors support the ability to power off components OF the CPU in order to enable them to achieve even greater energy savings, thus extending battery life.