Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

%CPU utilization is a lie

brendanlong.com

Post reply on HN
Print view View original

151–160 of 176 posts

Re: %CPU utilization is a lie

#151

Post by PathOfEclipse »

fluoridation wrote: post #131
PathOfEclipse wrote: post #125

I think it was always a mistake to pretend hyperthreading doubles your core count. I always assumed it was just due to laziness; the operating system treats a hyperthreaded core as two "virtual cores" and schedules as two cores, so then every other piece of tooling sees double the number of actual cores. There's no good reason I know of that a CPU utilization tool shouldn't use real cores when calculating percentages…

>There's no good reason I know of that a CPU utilization tool shouldn't use real cores when calculating percentages On AMD, threads may as well be cores. If you take a Ryzen and disable SMT, you're basically halving its parallelism, at least for some tasks. On Intel you're just turning off an extra 10-20%.

Can you provide some links for this? A quick web search turns this up at near the top from 2024:

https://www.techpowerup.com/review/amd-ryzen-9-9700x-perform...

The benchmarks show a 10% drop in "application" performance when SMT is disabled, but an overall 1-3% increase in performance for games.

From a hardware perspective, I can't imagine how it could be physically possible to double performance by enabling SMT.

Re: %CPU utilization is a lie

#152

Post by Sohcahtoa82 »

PaulKeeble wrote: post #20

This is bang on, you can't count the hyperthreads as double the performance, typically they are actually in practice only going to bring 15-30% if the job works well with it and their use will double the latency. Failing to account for loss in clockspeed as the core utilisation climbs is another way its not linear and in modern software for the desktop its really something to pay careful attention to. It should be po…

Back when I got an i7-3770K (4C/8T), I did a very basic benchmark using POV-Ray.

Going from 1 thread to 2 threads doubled the speed as expected. Going from 2 to 4 doubled it again. Going from 4 to 8 was only ~15% faster.

I imagine you could probably create a contrived benchmark that actually gives you nearly double the performance from SMT, but I don't know what it would look like. Maybe some benchmark that is written to deliberately constantly miss cache?

Side note, I should run that POV-Ray test again. It's been years since I've even use POV-Ray.

Re: %CPU utilization is a lie

#153

Post by kiitos »

kristopolous wrote: post #141
bionsystem wrote: post #77

Earlier quoted context omitted.

Happened to me on a different topic, felt bad for way too long ; in hindsight I'm pretty sure I dodged a bullet.

This was the same interview where some guy was asking me about "big-o" - like the thing that you teach 19 year olds and I was saying that parallelization matters, i/o matters, quantization matters, whether you can run it on the GPU, these all matter. The simple "big-o" number doesn't account for whether you need to pass terabytes over the bus for every operation - and on actual computers moving around terabytes, I kn…

"big o" usually refers to algorithmic complexity, which is something entirely orthogonal to all of the dimensions you mentioned

obviously all of this stuff matters in the end but big-o comes before all of those other things

Re: %CPU utilization is a lie

#154

Post by paravz »

saagarjha wrote: post #118
kqr wrote: post #76

It might be a lie, but it surely is a practical one. In my brief foray into site reliability engineering I used CPU utilisation (of CPU-bofund tasks) with queueing theory to choose how to scale servers before big events. The %CPU suggestions ran contrary to (and were much more conservative than) the "old wisdom" that would otherwise have been used. It worked out great at much lower cost than otherwise. What I'm tryin…

40% seems quite lightly utilized tbh

Cpu utilization %% needs to be contrasted with a "business" metric like latency or RPS. Depending on the environment and hardware 40% can be too utilized or way underutilized

Re: %CPU utilization is a lie

#155

Post by biggusdickus69 »

codedokode wrote: post #148

A worse lie is memory usage reporting, I think in every major OS it is understated and misreported. In case with Linux, I wanted to know who is using memory, and tried to add PSS values for every process, I never got back the total memory usage. In case with Windows/Mac I judge by screenshot of their tools which show unrealistically small values. As for the article, the slowdown can be also caused by increased use of…

The memory usage is interesting, where different kind of shared memory is obvious hard to visualize, just two values per process doesn’t say enough.

Most users actually wants a list of ”what can I kill to make the computer faster”, I.e. they want an oracle (no pun) that knows how fast the computer will be if different processes are killed.

Re: %CPU utilization is a lie

#156

Post by fluoridation »

PathOfEclipse wrote: post #151
fluoridation wrote: post #131

Earlier quoted context omitted.

>There's no good reason I know of that a CPU utilization tool shouldn't use real cores when calculating percentages On AMD, threads may as well be cores. If you take a Ryzen and disable SMT, you're basically halving its parallelism, at least for some tasks. On Intel you're just turning off an extra 10-20%.

Can you provide some links for this? A quick web search turns this up at near the top from 2024: https://www.techpowerup.com/review/amd-ryzen-9-9700x-perform... The benchmarks show a 10% drop in "application" performance when SMT is disabled, but an overall 1-3% increase in performance for games. From a hardware perspective, I can't imagine how it could be physically possible to double performance by enabling SMT.

I don't. It's based off my own testing, not by disabling SMT, but by running either or parallel threads. It was my own code, so it's possible code that uses SIMD more heavily will see a less-significant speed-up. It's also possible I just measured wrong; running Cargo on a directory with -j16 and -j32 takes 58 and 48 seconds respectively.

>From a hardware perspective, I can't imagine how it could be physically possible to double performance by enabling SMT.

It depends on which parts of the processor your code uses. SMT works by duplicating some but not all the components of each core, so a single core can work on multiple independent uops simultaneously. I don't know the specifics, but I can imagine ALU-type code (jumps, calls, movs, etc.) benefits more from SMT than very math-heavy code. That would explain why rustc saw a greater speedup than Cinebench, as compiler code is very twisty with not a lot of math.

Re: %CPU utilization is a lie

#157

Post by SirMaster »

magicalhippo wrote: post #105
MBCook wrote: post #66

Earlier quoted context omitted.

At the same time, it takes a certain amount of time for a CPU to switch power levels, and I remember it being surprisingly slow on some (older?) processors. So in Linux (and I assume elsewhere) there were attempts to figure out if the cost in time/power to move up to a higher power state would be worth the faster processing, or if staying lower power but slower would end up using less power because it was a short tas…

I deliberately put my govenor to the conservative one, as I hated fans spinning up for a second and then down again repeatedly. Much rather sacrifice a bit of battery and speed for quiet.

Can't you just cap the fan speed? Or does it actually get too hot at a lower fan speed to where it would throttle or crash?

Re: %CPU utilization is a lie

#158

Post by magicalhippo »

SirMaster wrote: post #157
magicalhippo wrote: post #105

Earlier quoted context omitted.

I deliberately put my govenor to the conservative one, as I hated fans spinning up for a second and then down again repeatedly. Much rather sacrifice a bit of battery and speed for quiet.

Can't you just cap the fan speed? Or does it actually get too hot at a lower fan speed to where it would throttle or crash?

I wanted the full power when doing long compiles and such. Just not the fan jojo acion when neowsing the web or writing.

Also swapping the governor was trivial and reliable. Modifying fan profiles has always been a bit of a struggle for me, with huge differences in hardware support, persistence etc.

Re: %CPU utilization is a lie

#159

Post by porridgeraisin »

magicalhippo wrote: post #158
SirMaster wrote: post #157

Earlier quoted context omitted.

Can't you just cap the fan speed? Or does it actually get too hot at a lower fan speed to where it would throttle or crash?

I wanted the full power when doing long compiles and such. Just not the fan jojo acion when neowsing the web or writing. Also swapping the governor was trivial and reliable. Modifying fan profiles has always been a bit of a struggle for me, with huge differences in hardware support, persistence etc.

> jojo acion when neowsing

jumping into action when browsing

Re: %CPU utilization is a lie

#160

Post by kristianp »

swiftcoder wrote: post #89

I remember being stuck in a discussion with management one time, that went something like this: Manager: CPU utilisation is 100% under load! We have to migrate to bigger instances. Me: but is the CPU actually doing useful work? (chat, it was not. busy waiting is CPU utilisation too)

How do you measure the amount of busy waiting?
Post reply on HN