101–110 of 181 posts
Clearly that's a different kind of situation; how do you distinguish the two?
Earlier quoted context omitted.
3.5 GHz instead of 4.1 GHz is a 15% difference, not 30%. I never expect multicore performance to be the same as single-core so if that's what you're assuming, it's an unreal assumption. I expect lower clock speeds for multicore regardless of what Task Manager shows. But okay, so there's some discrepancy, whether 15% or 30%. Okay, so I might underestimate it, and... then what? What would actually go wrong? I think wha…
It sounds like you don't ever engage in capacity planning. You should read about it, real usage numbers are very important.
And I'm just talking about what 99% of ordinary users expect most of the time. Nothing prevents you from measuring whatever metrics you want either. Obviously "I think this is what most people expect utilization to mean" obviously does not imply "I think you should be banned from anything else you might find useful"...
Earlier quoted context omitted.
Whatever frequency it could execute the next cycle at, assuming there was no desire to minimize power usage. It's a transient measure, not a steady-state measure.
The manufacturer doesn't know this, nor is it easy to determine. Is the max turbo frequency on air the max? On water (if so with what size rad with which fans)? At what ambient temperature? Is the max including tau, if so does that max change when it's about to expire? What about if the CPU was on ln² but the user has run out and can't add more to the cooling pot? Every one of those numbers is different, and frequent…
Name is probably wrong but it definitely exists.
A key problem with this proposal is that modern CPUs do not have a single definitive maximum frequency. You have the base frequency which is rarely relevant outside of synthetic workloads then you have a variety of turbo frequencies which interact in complex ways. AMD's latest CPUs don't even have clear upper bounds on their frequency scaling logic. It's a big black box and the results can vary depending on the workl…
That’s hard to do without hardware support, but I wonder how hard it would be to get a decent metric with currently available performance counters.
Earlier quoted context omitted.
i think you could prove that on linux by getting the number of instructions run. I think perf has a way of getting that info for you. not sure if windows has something simmilar
Hmm, different workloads will have different mixes of instructions, which will take very different amounts of time per instruction (e.g. a chain of uncached memory lookups vs a tight loop of register-register arithmetic). If you had two instances of the same workload, and one was throttled, then yes, you could compare instructions per unit time. But comparing prime95 vs the other benchmark is likely misleading.
I think we can have more nuance than a choice of 50% or 100%. I fall in the 'Show 100%' camp for sure, showing 50% but not indicating why isn't particularly helpful without knowing the background here. I think a separate indicator for an overall throttling condition would be helpful. Show a 100% usage and a throttle indicator together.
A key problem with this proposal is that modern CPUs do not have a single definitive maximum frequency. You have the base frequency which is rarely relevant outside of synthetic workloads then you have a variety of turbo frequencies which interact in complex ways. AMD's latest CPUs don't even have clear upper bounds on their frequency scaling logic. It's a big black box and the results can vary depending on the workl…
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…
Both are extremely complex with a lot of nuance after that but the "percentage time spent not idle due to program" type this article refers to tends to be simpler than trying to figure out cache/mode switches/instruction level parallelism/instructions per clock per type/and so on on top of everything you need to figure out in the first case anyways.