4 ms·
We're definitely interested in exploring this. Unfortunately it's likely a little slower than 4gb PC: Compression right now is basically a no-op, decompression
by verwaest 7y ago
We're definitely interested in exploring this. Unfortunately it's likely a little slower than 4gb PC: Compression right now is basically a no-op, decompression simply being a single add instruction. And it'll fragment memory a little because of the alignment requirements. But surely worth it for where larger heaps are necessary.
- the8472 7y agoDon't fancy x86 addressing modes provide most of those multiplications and offsets with very little IPC penalty?
- cfallin 7y agoYeah, this should be roughly the same overhead as an ADD: LEA rDest, [rBase + 8*rPtr] (The "load effective address" instruction computes an effective address like a load or store would, but just gives the address without doing a memory access.)
- the8472 7y agoAIUI mov supports these things directly[0] and if I read the instruction tables correctly then at least on skylake the latency/throughput is the same for all addressing modes[1] [0] http://www.c-jump.com/CIS77/ASM/Addressing/lecture.html#R77_0060_scaling_factors http://www.c-jump.com/CIS77/ASM/Addressing/lecture.html#R77_... [1] https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf (page 238)
- verwaest 7y agoDecompression isn't the problem, compression is. Compression is just a mov. Now we need additional shifts.
- verwaest 7y agoAlso we'll probably lose some cache benefits from compression due to larger alignment.