Why should your code not use 100% CPU? [closed]

Question

I'm speaking specifically about a C# .NET 4 program running on Windows XP or higher, but general answers are also acceptable.

Assume an already optimized and efficient program. The problem here is entirely down to effects of high CPU usage on hardware, and whether a high-usage program should be throttled to reduce wear, not on whether my implementation is efficient.

A colleague today suggested that I should not aim for 100% CPU utilization on my data load processes because "modern CPUs are cheap and will degrade quickly at 100% CPU".

Is this true? And if so, why? I was previously under the impression that 100% CPU usage was preferable for an intensive or long operation, and I couldn't find any respectable sources on the subject either way.

Answer 1

If cooling is insufficient, the CPU might overheat. But they all (well, at least all modern PC CPUs) feature various thermal protection mechanisms which will throttle the clock speed or, as a final resort, shut down.

So yes, on a dusty laptop, 100 % CPU load could cause temporary problems, but nothing will break or "degrade" (whatever that means).

For CPU bound problems, 100 % CPU load is the right way to go.

As for application (UI) responsiveness, that's a separate concept from CPU utilization. It's entirely possible to have an unresponsive application that uses 1 % CPU, or responsive application that uses 100 % CPU. UI responsiveness boils down to amount of work done in the UI thread, and the priority of UI thread vs. other threads.

Answer 2

There is generally nothing wrong with a program using 100% CPU while it is actually doing useful work and is not taking time away from anything more important. If a particular hardware platform is e.g. only capable of using 100% CPU continuously for one second before it has to throttle back to 50% to avoid overheating, it is generally better for an application which has useful work to perform to run as fast as it can, and let the CPU or OS handle any necessary throttling, than for an application to guess how fast it "should" run. If an application or thread has low-priority work to do which would be useful but not at all time critical, it may be helpful for the OS to limit low-priority-task CPU usage to 50% so that if the CPU needs to do something quickly it will be ready to "sprint" for a second, but the application shouldn't worry about such things beyond requesting a low thread priority.

The biggest situations where it's bad to use 100% CPU are when either:

• The application is busy-waiting for some event which isn't going to be hastened by persistent polling [and might actually be delayed if the effort wasted checking whether the task is done occupies CPU resources which could otherwise be spent doing the task].

• The application is redrawing the display excessively often. The definition of "excessively often" will depend in some measure upon the nature of the display device and the content being shown. If display hardware can display 120fps, there may be cases where animation could be shown at 120fps without adding motion blur, but could not be shown cleanly at lower frame rates without adding it. If rendering a frame with motion blur would take much longer than rendering it without, then rendering at 120fps on hardware which supports it could actually be no more costly than rendering at a slower frame rate with motion blur. [Simple situation: a wheel with 29 spokes, rotating at one revolution per second. At 120fps, the wheel would appear to rotate with the proper speed and direction; at 60fps, a flickering wheel would appear to rotate slowly in the opposite direction].

The former is clearly recognizable as bad. The second is a bit more subtle. If one is targeting a mobile platform, it may be desirable in some cases to allow users to select the desired animation frame rate, since some users may not be worried about battery life but would want the best quality animation, while others would accept lower quality animation in exchange for better battery life. Rather than having the application try to guess where the trade-off should be, it may be helpful to let the user customize it.

Answer 3

Windows programs (winforms/WPF) should at all times stay responsive. With a naive implementation of a process that uses 100% cpu resources it's all too easy to make your program or even your system seem sluggish and hanging.

With a good implementation (for instance: use a seperate thread with lower priority) it shouldn't be a problem.

You shouldn't worry about your cpu breaking sooner.

Answer 4

"modern CPUs are cheap and will degrade quickly at 100% CPU".

I don't think anyone's actually addressed the "degrade" part of this question. ICs will degrade when the die temperature exceeds the manufacturer's limits. ICs are usually designed to operate up to 125C, although every 10C increase shortens life by 50%

Processors didn't always have thermal regulation. Then some AMD Durons experienced problems (allegedly it was possible to destroy one if run without heatsink). Now all PC processors will have builtin temperature sensors that feed back into the CPU clock, and will slow down the clock to prevent damage. So you may find that your program is using 100% of available CPU but the CPU is only running at 75% of its rated speed because its cooling is inadequate.

Within a user program is not the correct place to try to manage CPU consumption. Generally your program should alternate between doing things as fast as possible and waiting, suspended, for input or disk access. You should avoid busy-waiting and spinlocking if possible, but as a courtesy to the rest of the system.

Both Windows and Linux have CPU "govenor" systems that will do performance and thermal management. Because this is done at the OS level it can account for total system CPU consumption. It is the responsibility of the operating system to manage the hardware and prevent user programs from misusing it. It is the responsibility of the hardware owner to keep the fans clean and working, and the manufacturer to fit adequate heatsinks and fans in the first place.

There are a few cases where devices have inadequate cooling, but a flood of returns teaches the manufacturers not to do that.

Answer 5

To play the devil's advocate: In a way, a program that cannot reach 100% utilization could cause worse wear: Unless it is suspended waiting for a keystroke, chances are that it is suspended waiting for disk I/O most of the time. And disks are (still usually) big mechanical devices that are subject to mechanical wear or the risk of shock/gyroscopic effects when they move, not to mention power consumption.

Answer 6

"..modern CPUs are cheap and will degrade quickly at 100% CPU".

You don't have to worry about "CPU degradation" at all. Modern CPUs are not of less quality than in former times.

It is very expensive (and is getting more expensive every couple of years) to make CPUs, some billions to build a new fab are not uncommon (see link).

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

The production costs of a CPU depends at most on the no. of units produced. This is a well known fact in economy. That's the reason they can be sold (relatively) "cheap" after all. (I think, no link necessary here)

I can list a number of reasons why I would consider modern CPUs to tend to be of more quality than in "former times".

But only the most important: Advantages in testing. Modern electronics are "designed for test". Whether software or hardware, the broad insight of valuing tests over nearly everything else, is not so old. For CPUs, the tests are even taken for forming the different price and frequency types, e.g. the best CPUs are sold with highest frequencies. Despite that, the cheaper processors are very often able to operate with higher frequency than sold- they are crippled only for the reason that the manufacturer wants to sell some "high level" processors with higher prices.

(One the other hand, of course there are more errors possible for a processor with more than 1.5 billion transistors as normal nowadays than with some thousand transistors of a processor of the seventies. But this does not contradict to my answer IMO. Processors in general tend to have many known errors, at least in microcode, but this is not subject here.)

There are even more reasons not to worry about CPU degredation for your program:

• First reason is that modern CPUs decrease their frequency or throttle, if they are getting too hot.

  It should be clear that if you utilize the CPU 100% 24/7 the whole year it will normally die earlier than a CPU only used every second week one hour. But that is true for cars, too, by the way. Only in such cases I would think about CPU utilization and potential sleeps yourself.

• Second reason is that it is really very hard to write a program which uses 100% of the CPU from OS, (e.g. in Windows). Besides, modern CPUs (normally) have at least 2-4 cores. So a traditional algorithm which tends to use 100% of a single core CPU, now has only 50% on a dual core CPU (simplified but seen in real scenarios).

• Moreover the operating system has the control over the CPU and not your program, so if there are other applications with same or higher priority (what is the default), your program is only getting as much CPU as possible, but the other applications will not starve. (Of course this is only the simplified theory, and of course the multitasking of Windows, Linux and others is not perfect, but overall I would consider that for true).

"I was previously under the impression that 100% CPU usage was preferable for an intensive or long operation.."

Yes, stay with this. But for example, if you do waiting&looping for another process, in other words doing nothing, it would be not too bad if you Thread.Sleep() some milliseconds in that loop, giving extra time to others. Whereas it is not necessary for a good multitasking OS, I solved some issues with this e.g. for Windows 2000. (That does NOT mean of course to use Sleep() in calculations for example..

Answer 7

Such degradation is theoretically possible and is called "electromigration". Electromigration is temperature-dependent, accelerating as the temperature goes up. Whether it is a practical problem for modern CPUs is up for debate. Modern VLSI design practices compensate for electromigration and chips are more likely to fail for other reasons.

Having said that, electromigration happens even at normal loads and temperatures, but it is slow enough that a well-designed chip either becomes obsolete far before failing, or it fails via another mechanism first.

The rate of electromigration depends on the chip temperature, with the lifetime doubling for every (very roughly) 10°C. This is, in fact, the basis of a test called "HTOL" (high temperature operating life), which measures how long it takes for a chip to die at, say, 125°C. A chip running at 125°C will fail roughly 100 times faster than a chip running at 55°C, so if designed to last at least 10 years at 55°C, a chip might fail within 1 month at 125°C. If running at something more reasonable like 85°C, such a chip would still fail at least 5-10x sooner than it was designed for.

Of course, CPUs are usually designed with higher temperatures in mind, so they can typically last for years at 85°C 24/7 100% load operation. So I would suggest that you don't worry about "wearing out" the CPU, and only worry about whether a 100% load is appropriate from the software engineering perspective.

Answer 8

If you are running your code on clients, 100% CPU utilization means that client computers in that time cannot be used for anything else but tasks with higher priority. As most applications usually run in default priority, users using those computers will notice computer freezing and will be unable to do ought else on their computers. Even if we are talking about short bursts, users working on something will still notice it.

As others said, you were pretty secretive about the setup, so I cannot say for sure. But, if your clients are desktop computers, stay away from 100% CPU utilization. Not because of CPU degradation, but because it is not good form to disrupt users during their work.

Answer 9

So the situation is this: You have some code that runs say for five hours using 100% of all CPUs, that is optimised as much you can, the owner of the machine is fine with the machine being unusable for five hours, and your colleague claims it would be better to run your code in 6 hours using 83.33% of all CPUs, because it puts less wear and tear on the computer.

It depends on the computer that you are using. I know that a computer manufacturer refused warranty repairs within the warranty time on cheap home computers that were used in a scientific setting running 24/7. They clearly wanted the customer to buy their more expensive servers or "business" computers. Whether they were successful, I don't know.

Every Mac that I've owned has at some point in its life run code at 100% CPU usage for days at a time. In one case I had to turn the display off, because I didn't have the original charger for a laptop, and with 4 cores and hyper threading it used more power than the charger supplied - so the battery went down, and when it reached 5 percent the computer slowed down the clock speed until the battery was up to 10% ! (With the display turned off it ran at full speed for several days). In no case, any ill effects.

So with a well-designed computer, you are right. With a badly designed, cheap computer, your colleague might be right. On the other hand, you might consider the cost of your waiting time vs. the cost of buying a replacement computer.

Answer 10

If you can, make your code a lower priority task, and make sure to keep the CPU-heavy thread separate from the GUI. Then you might have 100% utilization, but the user can always still run other tasks and stay responsive. By itself, a CPU is designed to stay running at 100% usage for a while, or it would not get released. Unless the end user has made serious and dangerous modifications to their hardware, you can't damage anything.