4 ms·
If the problem is that a significant amount of cache is routinely wasted by storing many pointers of the form: 0xffffffffxxxxxxxx and 0x00000000xxxxxxxx, then I
by gnode 8y ago
If the problem is that a significant amount of cache is routinely wasted by storing many pointers of the form: 0xffffffffxxxxxxxx and 0x00000000xxxxxxxx, then I wonder why CPU designers haven't added an optimisation to their caches to store these numbers in 32-bit (or slightly larger) cells.
- pedrocr 8y agoThe CPU caches are caching normal memory pages. From the point of view of the CPU it doesn't know if what it's caching is a pointer or just any other random 64bit number until the code actually does anything with the cache. What you are suggesting might work generally if it was somehow worthwhile to try and do some lossless compression of page contents before storing them in the CPU cache. If that's not done yet I'm sure it's because the energy and extra transistors needed for it are not worth it, and not because CPU designers haven't thought about it.
- gok 8y agoMemory compression is actually pretty widely used. Linux has zram, which Android and ChromeOS have on by default. macOS/iOS has something similar.
- gnode 8y agoI wasn't suggesting determining whether the values were pointers or not. The number itself suggests whether it can be stored with less bits. If the occurrence of such numbers were relatively high, then this becomes a sensible tradeoff. In set associative caches, one or more of the "ways" in each index could be optimised for these relatively common small numbers, with fewer bits given to it, capable of only storing numbers of the small form.
- pedrocr 8y ago> In set associative caches, one or more of the "ways" in each index could be optimised for these relatively common small numbers, with fewer bits given to it, capable of only storing numbers of the small form. But these aren't caches of 64bit numbers where that optimization would apply. These are caches of 4kb pages of bytes. And since this is x86 I don't think it's even guaranteed that pointers are 64bit aligned. Maybe for the TLB cache an optimization like that would be useful?
- gnode 8y ago> These are caches of 4kb pages of bytes. This isn't true. x86_64 CPUs use 64-bit cache lines, in associative sets. They don't have any caches which contain entire pages. The TLB stores the mappings for whole pages, if that's what you're thinking about?
- pedrocr 8y ago4kb was indeed too large but it's not 64bit either. They're 64byte cache lines, so the same applies.
- jlokier 8y agoI wouldn't be surprised if they have. Coincidence... I was just working on such an optimisation. But rather than compression as some commenters suggested, the method is to use separate cache lines for the low and high 32-bit halves, re-encoding values so that small signed and unsigned integers and JVM-style compressed pointers (> 4GiB) only need the low half, and keeping track of when the high half is not required. That saves cache space. Cache bandwidth to main memory can also be reduced, which also reduces energy consumption on the memory bus, but this is considerably more complicated and involves changes to the ECC encoding. The same method works with 32-bit pointers, non-pointer integers, and JVM-style compressed pointers over a larger than 32-bit range. These methods don't save RAM, but they do reduce cache pressure and memory bandwidth.