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

171–176 of 176 posts

Re: %CPU utilization is a lie

#171

Post by 0x457 »

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?

It's just bad fan curve for given workload. Sharp rises and drops are annoying to hear, curve that does that + race-to-sleep do not work together. Low speeds do cause throttling.

Re: %CPU utilization is a lie

#172

Post by 0x457 »

paravz wrote: post #154
saagarjha wrote: post #118

Earlier quoted context omitted.

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

I think CPU utilization is a "cause" metric and therefore irrelevant until it effects "business" metric.

Re: %CPU utilization is a lie

#173

Post by kristopolous »

kiitos wrote: post #167
nomel wrote: post #166

Earlier quoted context omitted.

> but big-o comes before all of those other things If you're attempting to quantify algorithmic scalability with big-o, without those in mind, you'll often be wrong. There was a great post here a few years ago going into this, and how memory access "complexity" is what usually matters, and what dominantly shapes the scalability curve. It had nice examples showing how the expected big-o scalability curves were often c…

algorithmic complexity is 100% absolutely orthogonal to the stuff you've mentioned what you're describing is something different than big-o, in the sense that is commonly understood, and what your interviewer almost certainly intended I understand what you're describing and talking about but it's not big-o I would guess that you haven't had any kind of formal cs education? no shade but like there are some important t…

But none of that is the point. This was at a well funded company looking for a high scalability engineer.

So excuse me for thinking that's what they're looking for and answering accordingly.

I literally only wanted to work there to team build, then snipe engineers and spin off into my own thing. So whatever.

Re: %CPU utilization is a lie

#174

Post by bboreham »

tgma wrote: post #2

The way they refer to cores in their system is confusing and non-standard. The author talks about a 5900X as a 24 core machine and discusses as if there are 24 cores, 12 of which are piggybacking on the other 12. In reality, there are 24 hyperthreads that are pretty much pairwise symmetric that execute on top of 12 cores with two sets of instruction pipeline sharing same underlying functional units.

Worth noting that the major clouds will sell this as 24 "vcpus".

Re: %CPU utilization is a lie

#175

Post by kiitos »

kristopolous wrote: post #173
kiitos wrote: post #167

Earlier quoted context omitted.

algorithmic complexity is 100% absolutely orthogonal to the stuff you've mentioned what you're describing is something different than big-o, in the sense that is commonly understood, and what your interviewer almost certainly intended I understand what you're describing and talking about but it's not big-o I would guess that you haven't had any kind of formal cs education? no shade but like there are some important t…

But none of that is the point. This was at a well funded company looking for a high scalability engineer. So excuse me for thinking that's what they're looking for and answering accordingly. I literally only wanted to work there to team build, then snipe engineers and spin off into my own thing. So whatever.

looks like both you and they dodged bullets in this outcome, so all worked out in the end

Re: %CPU utilization is a lie

#176

Post by bcrl »

ckozlowski wrote: post #39
tom_ wrote: post #26

Earlier quoted context omitted.

Why do they need so many threads? This really feels like they just designed the cpu poorly, in that it can't extract enough parallelism out of the instruction stream already. (Intel and AMD stopped at 2! Apparently more wasn't worth it for them. Presumably because the cpu was doing enough of the right thing already.)

As I recall it, Intel brought about Hyperthreading on Northwood and later Pentium 4s as a way to help with issues in it's long pipeline. As I remember it described at the time, P4 had 30+ stages in it's pipeline. Many of them did not need to be used in a given thread. Furthermore, if a branch prediction engine guessed wrong, then the pipeline needed to be cleared and started anew. For a 30+ stage pipeline, that's a l…

The P4's main problem wasn't so much the 30 stage pipeline. It was the fact that the CPU went off into la-la land for 4000+ cycles when replays occurred. The trigger could be anything as simple as a misaligned load or microcode for an 8 byte rep ; movs or a page fault. As a result, the performance of the design was very fragile and too sensitive to extremely small changes in code and data layout, in large part because of how the features to support high clock speeds all fit together. Performance tuning could often get substantial improvements for complex code paths, but the optimizations were frequently useless for other microarchitectures that didn't have the same glass jaws.

Hyperthreading was much less of a concern given that threading of software was only ramping up for mainstream x86.

Post reply on HN