31–32 of 32 posts
Earlier quoted context omitted.
I find it incredible how slow modern RAM and databuses are. A far cry from the early days where you could upgrade the CPU cache by inserting some memory chips on the other side of the board
ram has gotten steadily faster since then. but cpus have gotten faster, faster.
So they set aside 2 32-bit patterns; when these patterns appear at the end of a 64-byte cache line, they indicate a compressed line; otherwise, the line is literal. This smells an awful lot like an impossible infinite compression claim; any real compressor must increase the length of at least some inputs due to the pigeonhole principle. Their solution is to add a 16-entry table to track "lines that look like they hav…
Why even include this sentence when the rest of the post is about the extra state it uses to track collisions?
> Including just one bit of metadata per cache line of memory is 32MiB, more than the 0.75 bits/line (24MiB) calculated on page 5 for the scheme they would like to replace.
Sure? The point of this scheme is to not store any metadata per line of main memory.
> Their next bit of handwavium is that they use "DES" to choose line markers in a way dependent on a secret key which can be changed in case of a LUT overflow. I wasn't immediately able to find a modern figure on how fast hardware "DES" is, but a 2003 paper gives a figure of "21 to 37 cycles of latency" https://www.intopix.com/Ressources/WPs_and_Sc_Pub/intoPIX%20.... -- will this fit into the time budget or will it slow memory accesses? (They first say this is off the critical path but then that the marker is per-line, I don't see how both are true)
21 to 37 cycles is definitely lower latency than accessing memory. And you can easily pipeline it to match the rate of memory accesses.
> When the limited table is exhausted, a new key is chosen and all of memory must be updated (so you really don't want to do that) They dismiss this by again appealing to the rarity as "1-in-2^512" but if that's true you might as well just design the chip to blow up when the condition arises. If any timing information about "line appears in LUT" is visible to a program, then it is just 16 * 2^32 instead for an adversarial program (you can tweak line 1 until it needs a LUT entry, which takes just 2^32 writes; then repeat for the next line)
So an adversarial program can waste CPU? It can already do that.
But more importantly, the LUT only needs to be involved when checking the marker on a memory access. It should be very possible to make it fixed-timing.