Hacker News Reader

Comment by userbinator | Hacker News Reader

For source material that contains long runs of sequences (RLE), decompression is faster than memcpy.

This is not surprising given how RLE decompression works --- memcpy and regular LZ decompression requires copying data, i.e. a memory read followed by a memory write. RLE only requires a read of the value to be repeated, followed by multiple writes.

It is interesting to note that CPUs today are also often limited by memory bandwidth, just like the 8088/8086.

View on HN

It's not surprising if you think about it. But it may be surprising if you don't.

I wonder how 8-channel memory is going to change that on next gen server chips.

Memory is orders of magnitude slower than the cpu at the moment, so you'd need orders of magnitude more bandwidth to come close. So sure, it's going to be faster, but the cpu is still going to be waiting for memory more than the other way round.

I wonder if the heat-bound nature of especially mobile CPUs these days could contribute to memory "catching up" to CPU performance. That is, the CPU idle while waiting for memory could be seen as necessary for heat dissipation and so you could consider the CPU at capacity.

That's basically what I understand the idea of "race to halt" to be. Mobile CPUs are already designed to finish their current task as quickly as possible so they can idle to cool off (that's how laptop chips can support turbo boost).

I think the time it takes for memory reads is too short to take advantage of though, because of how long it takes chips to come out of sleep & ramp up their clock speed.

Litterally not at all.

L1 cache is 3-5x slower then a CPU register and it has a ~532GiB/s thought put. DDR4 is ~2GiB/a per channel.

Also DDR has extreme latency due to its distance from the die.

Physics is hard. In the cycle of a 2400MHz DDR4 clock, a photon travels 12.5cm. The memory bus distance is on a similar order of magnitude.

Main memory latency will be the big performance bottleneck for the foreseeable future.

Reply on news.ycombinator.com