Hmm, I feel like this is a bit too big of a generalization to be useful. It's a cool observation but I don't think you can interpet IPC so directly as to conclu

Hmm, I feel like this is a bit too big of a generalization to be useful. It's a cool observation but I don't think you can interpet IPC so directly as to conclude that IPC < 1 indicates "you are likely memory stalled". There are a million reasons why you'd have an IPC < 1, many of them which are not memory. Maybe you just have a lot of hard to predict branches which take a long time to resolve (all that mispeculated work is wasted cycles!), maybe you use a lot of long latency FP operations, maybe you just have really long dependency chains. If your core doesn't have full speculative wakeups for variable latency instructions (meaning things like loads but often things like division and multiplication have early exits), you can very easily end up with plenty of cycles where you don't complete an instruction. And, yes, of course, it could be that you're having a lot of cache misses. Memory is a good guess but it's not really actionable advice for performance analysis, you really need to pull out some proper tools to understand why you're getting that number. I think this is a cool article in that, yes, Task Manager/top/Activity Monitor aren't telling you the full story when it comes to what "CPU %" means. In the end though, there really isn't an easy way to come up with a better metric for utilization that can be summarized in one number, so realistically "how much time did the scheduler put this process on a core for" is plenty good enough for most purposes.