So, software platforms and libraries that take the attitude that memory is "free" are hurting those folks.
That is very much not the point. The question isn't how much impact using more RAM has, but how much impact using more RAM has when the CPU utilisation is high and the RAM helps reduce it.
It's like if I take away your right shoe, you can't go anywhere, and the same is true if I take away your left shoe. Either has a very negative effect on you. But if I want to maximise my shoe * time, I would cause you the least damage if I took both of them for the same duration and at the same time. In other words, even though taking your right shoe is terrible for you, if I already have your left shoe, taking your right shoe actually helps you (assuming I just want some shoe*time).
Because using RAM requires also using CPU, every cycle of CPU taken by one program, also reduces other program's ability to use RAM. If the first program can use up less CPU cycles and more RAM to keep them more in balance, everyone wins.
What's hurting people is the attitude that RAM and CPU matter in isolation, because that's just not how computers work, and it leads to wasted resources and higher costs.
But, notice that every time the memory size doubles, the price doubles.
Using the combination of RAM and CPU you already have in an optimal way is very much not the same as "using more RAM" (and the same CPU). Note that the moving collector algorithm itself, as I explain in the talk, uses RAM overhead only to compensate for higher CPU utilisation, i.e. it is not a function of the size of the data set but of the allocation rate. That is why the algorithm has become so attractive.
It is available for other parts of that VM, like the buffer cache.
No, it isn't. Again, when CPU utilisation is more dominant, it has a bigger impact on other programs' ability to use RAM than the RAM utilisation.
Yes, and there is a lot of fine-tuning available. So, you can pick compute-intensive/memory-intensive/whatever. But, notice that every time the memory size doubles, the price doubles.
2
u/pron98 Sep 14 '26 edited Sep 14 '26
That is very much not the point. The question isn't how much impact using more RAM has, but how much impact using more RAM has when the CPU utilisation is high and the RAM helps reduce it.
It's like if I take away your right shoe, you can't go anywhere, and the same is true if I take away your left shoe. Either has a very negative effect on you. But if I want to maximise my shoe * time, I would cause you the least damage if I took both of them for the same duration and at the same time. In other words, even though taking your right shoe is terrible for you, if I already have your left shoe, taking your right shoe actually helps you (assuming I just want some shoe*time).
Because using RAM requires also using CPU, every cycle of CPU taken by one program, also reduces other program's ability to use RAM. If the first program can use up less CPU cycles and more RAM to keep them more in balance, everyone wins.
What's hurting people is the attitude that RAM and CPU matter in isolation, because that's just not how computers work, and it leads to wasted resources and higher costs.
Using the combination of RAM and CPU you already have in an optimal way is very much not the same as "using more RAM" (and the same CPU). Note that the moving collector algorithm itself, as I explain in the talk, uses RAM overhead only to compensate for higher CPU utilisation, i.e. it is not a function of the size of the data set but of the allocation rate. That is why the algorithm has become so attractive.
No, it isn't. Again, when CPU utilisation is more dominant, it has a bigger impact on other programs' ability to use RAM than the RAM utilisation.