4 ms·
>"Whether this is a net win depends on the memory access patterns of the applications you use. If you had an application that had 6 very hot pages, and 14 addit
by peter_d_sherman 4y ago
>"Whether this is a net win depends on the memory access patterns of the applications you use. If you had an application that had 6 very hot pages, and 14 additional warm pages, then this could very well be an improvement, since the very hot pages could stay in normal memory, and the 14 warm pages could take turns occupying the two remaining normal memory pages. On the other hand, If you had an application that had 10 very hot pages, and 10 additional warm pages, then this could end up a net loss, because there aren’t enough normal pages to hold the application’s very hot pages, so you are constantly compressing and decompressing memory, and that extra time spent on compression could exceed the time saved by avoiding the I/O to the four pages that didn’t fit in RAM before."
This is an excellent point!
Also -- another observation (for future CPU engineers): The interception and on-the-fly compression/decompression of memory pages that were decided to be swapped out to disk -- is currently handled by additional software which implements this functionality. (zstd for swapfile, etc.)
But, maybe in future computers -- this shouldn't be handled by software...
Maybe a future CPU, if well engineered -- would implement page tables with extra information -- not just a bit that says "this page is present/absent in/from memory" -- but also a bit that might say that it has been compressed and cached to a special pre-determined section of memory by the CPU (and/or cached on the CPU itself) -- which also has onboard compression/decompression hardware specifically created for this purpose...
In other words, it might make sense to move all of this functionality to a future CPU -- where the compression/decompression could get done completely in hardware (should be much faster than software if properly engineered) -- and if a page can't be compressed -- then the CPU hardware "knows" that -- in, or in close to real-time...
Such a CPU should allocate extra data in its page tables for storing advanced statistical data about the historical "heat" of a page -- such that it could decide the best policy for it on-the-fly -- swap to disk, compress/decompress on-the-fly, or simply keep in memory and swap or compress out a different less "hot" page...
Anyway, there is no doubt some future work to be done in that area...
If the engineering for this was absolutely perfect -- then the net effect is that future computers would have X [MB,GB,TB,PB,?] of physical RAM like they do now -- but they'd appear to have Y [MB,GB,TB,PB,?] of RAM -- where Y is greater (much greater!) than X, and where all of that extra "compressed/virtualized" memory -- runs at the exact same speed that regular memory does now!
Impossible to engineer?
Well, maybe... but that would be the ideal, the pinnacle of that engineering -- if it could be obtained...
And I think it would be interesting to try, no matter what the outcome -- even if the effort failed, something would be probably be learned that might help the next future engineering effort...