Earlier quoted context omitted.
CPU usage is an incredibly complex metric that doesn't really explain what is actually going on. I noticed while running a benchmark I can get my CPU to 50c and 100% usage and it stays steady like that. But then I tried prime95 and my cpu very quickly hit 99c also at 100%. Likely the different benchmarks were both running as fast as they can but the prime95 one ran on a faster part of the cpu which could generate mor…
> my cpu very quickly hit 99c also at 100% That should never happen and it's ridiculous that we just let manufacturers get way with it.
What should the CPU usage be of a fully-loaded CPU that has been throttled?
141–150 of 181 posts
Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#142Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#143Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#144Earlier quoted context omitted.
Why? 100c is typically the max nominal safe operating temp for CPUs. It would be a waste of resources to add additional cooling to computers not intended to run these type of workloads. Prime95 is basically a synthetic workload so it makes little sense to optimize for it.
How did you determine that 100c is safe?
Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#145Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#146Earlier quoted context omitted.
How did you determine that 100c is safe?
In extension to what the other commenter said, critical temperature that is listed is usually higher than the maximum operating temperature so it is safe to run at the maximum.
At 100 the processor is at high risk of damage, which is why there's a built-in throttling mechanism.
Just imo, if it was safe it would be running at full speed (or at least max base clock) at that temperature.
As someone else said, they're made for burst operation these days, but again, that does not excuse manufacturers using subpar cooling.
I can see the majority is fine with it, but I'm not. A 15-25% failure rate in 2 years would make any other product a rotten lemon. But somehow it's acceptable for computers. Probably because people replace them every 2 years regardless, which is another insanity on its own.
Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#147Earlier quoted context omitted.
Yeah, the thing is it doesn't only happen in prime95. Nowadays it's any prolonged use where the CPU is fully used, like video editing or gaming. Give an inch and they'll take a mile, as the saying goes. Temperature junction throttling is a last resort. No laptop should rely on it in normal operation. Of course, both HP/Dell/Lenovo/etc and Intel benefit from increased sales so they don't care.
Counterpoint - during typical (consumer) usage hardware spends most of the time idle. Hardware capable of sustaining the maximum workload indefinitely is likely to have a lower maximum in practice. Unsustainable bursts are likely to provide higher overall performance for typical workloads, so it makes sense to optimize the hardware design for those.
Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#148Earlier quoted context omitted.
CPU usage is an incredibly complex metric that doesn't really explain what is actually going on. I noticed while running a benchmark I can get my CPU to 50c and 100% usage and it stays steady like that. But then I tried prime95 and my cpu very quickly hit 99c also at 100%. Likely the different benchmarks were both running as fast as they can but the prime95 one ran on a faster part of the cpu which could generate mor…
> my cpu very quickly hit 99c also at 100% That should never happen and it's ridiculous that we just let manufacturers get way with it.
Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?
#149I was trying to optimize some FEM code, toying with (hardcoded) solver parameters. On one console I had it spitting out the wall clock durations of time steps as the simulation was running, while on the other I was preparing the next run. I start compiling another version, and inexplicably the simulation in the other console gets faster. Like, 10%-20% less time taken per time step. "That must have been coincidence. There's no way the simulation got faster by compiling something in parallel." But curiosity got the better of me and I still investigated.
Watching the CPU speed with CPU-Z, it turned out that the simulation was indeed getting down-clocked, and that compiling something in parallel made the CPU run faster, speeding up the simulation too. WTF? And indeed, I could make the entire simulation run significantly faster by calling
std::thread([](){ while (true); });
at the start of main.Why? Well, the simulation happens to be extremely memory-bound (sparse mat-vec multiplication in inner loop). So the CPU is mostly waiting around for data to arrive. Apparently the CPU downclocks as a result. That would be fine, if not for the fact that the uncore/memory subsystem clock speed is directly tied to the current CPU speed. That's right: The program was memory-bound, hence the CPU clocked down, hence the uncore clocked down, hence memory accesses became slower.
Knowing that feedback loop, it makes perfect sense that keeping the CPU busy with a spinning thread improves performance. But it's still one big wtf.
This problem eventually went away as we parallelized more and more of the simulation, giving the CPU less reason to clock down. But for related reasons, the simulation still runs faster if you prevent hyperthreading (either by disabling it in BIOS or having num threads = num hardware cores). More threads don't improve memory bandwidth and the hyperthread pairs just step on each others toes.