|
|
|
|
|
|
by setr
16 days ago
|
|
|
> This is because taking up 100% of the CPU effectively captures 100% of RAM Isn’t that only true though specifically at 100% CPU utilization? If it were at 90% CPU, then you have no RAM capture, and then you can’t say anything about whether 80 or 800MB should be taken; it’s only a freebie if and only if literally no other program can do work on the machine. I don’t see how you can map X% CPU utilization to Y% RAM capture. Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work. The CPU / RAM capture ratio would be wildly different; the ideal for your program, while other competing programs of unknown behaviors exist, I don’t see any way for hotspot to approximate |
|
|
No. Because any RAM access requires CPU, using up any CPU effectively captures some ability to use RAM.
> I don’t see how you can map X% CPU utilization to Y% RAM capture.
You're right that there isn't a fixed formula, but the most efficient balance can have a narrow range, because CPU and RAM are typically sold as a package with a rather narrow RAM/core ratio (usually between 0.5 and 4GB, where the lower end is usually when you have slow cores). This is also because of the intrinsic relationship of RAM and CPU.
> Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work.
A program that is very CPU light can't make use of a lot of physical RAM at any one time (again, because using RAM requires CPU). Once exception is caching, but memory access patterns for caching are easily detectable, and you can (and Java does) offer a different balance for them. I covered that in my talk, which will be eventually published on YouTube.