Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

arxiv.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#21

Post by blattimwind »

cramcram wrote: post #10

Their assumption of 64 bytes cacheline is unrealistic. Most CPU architecture use 64 bit cacheline (1/8 of 64 bytes), for good reasons. 512 bit cacheline is insane. Also, good compression requires large corpus / large model - thus page-based compression is much more useful in real life. For example Google's ChromeOS uses zram by default since 2013 [1]. [1] https://en.wikipedia.org/wiki/Zram

> Most CPU architecture use 64 bit cacheline (1/8 of 64 bytes), for good reasons. 512 bit cacheline is insane.

No. 64 and 128 (to a lesser extent) bytes are pretty much the only extant cache line sizes these days.

64 bit cache lines would be insane.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#22

Post by TomVDB »

puzzle wrote: post #20
sprash wrote: post #8

Earlier quoted context omitted.

Yes it also only works well with GPUs. GPU-Ram communication is all about bandwidth. General purpose CPUs are all about latency. Only very specialized problems would benefit from memory compression. On the other Hand compression will increase latency which is counterproductive to any traditional CPU tasks.

I thought that HDMI and DisplayPort used compression, too, sometimes. Even then, your point about generic computing still stands.

HDMI and DisplayPort have Display Stream Compression.

However, there are currently no known sources that support it, and it’s a lossy compression.

Since bandwidth requirements are going up faster than thr bandwidth of cables, one can expect DSC to be common once 8K displays are a thing.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#23

Post by TomVDB »

moonbug wrote: post #19

GPU vendors have been doing this with texture maps for years.

Texture map compression is lossy, and it’s a very compute intensive process that is done at the game mastering time, and it’s a fix ratio compression.

None of this is the case here.

You’re probably thinking about delta color compression.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#24

Post by ahartmetz »

deagle50 wrote: post #17
sprash wrote: post #8

Earlier quoted context omitted.

Yes it also only works well with GPUs. GPU-Ram communication is all about bandwidth. General purpose CPUs are all about latency. Only very specialized problems would benefit from memory compression. On the other Hand compression will increase latency which is counterproductive to any traditional CPU tasks.

Even though the trend is toward GPUs, we'll likely be running large amounts of throughput workloads on CPUs for another decade. A 5% reduction in power consumption is worth exploring. Is it bad that I'm looking forward to the end of Moore's law (a little)?

With my specialty in native code, I am already benefiting from the end of Moore's law. Now, a factor 2 in performance actually matters. I also expect to see more specialized hardware and software to, say, feed 8K screens, process many small independent transactions (high core count servers), etc. There is going to be a lot of interesting performance work :)

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#25

Post by mrguyorama »

miohtama wrote: post #16

BLOSC already does this with software. http://blosc.org/ The sales pitch is "faster than memcpy." Fetch data from RAM, decompress it in L1,2,3 caches and run operations on the data. Some very nice benchmarks available.

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

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#27

Post by nawgszy »

Arkanosis wrote: post #26

The “CRAM” name is already used by a NGS file format (for compressed sequences storage): http://www.internationalgenome.org/faq/what-are-cram-files/ .

Is that supposed to be a dealbreaker? I imagine 4 letter acronyms, especially ones that are also words, are in short supply these days.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#28

Post by hinkley »

js8 wrote: post #4

I wonder how it would fare compared to "software-only" solution, that is re-architecturing your algorithm to work with compressed data directly. For example, consider an analytical engine going over values in a column of a database to sum it together. To increase the bandwidth, you can consider compressing the values (for example, with some form of Huffman encoding), and you have two options: 1. Decompress the values…

You glossing over the ugly truth here. Structured data and mutable data don't respond well to the type of operations you're talking about, and that is most of the interesting data in most programs.

Most data requires random access to the middle, which is something compression is usually very bad at doing cheaply. You would have to leave boundary markers which eats into your size and speed advantage.

Updating a record will change its length, requiring you to reallocate and possibly rewrite subsequent values, or even the entire parent data structure. Imagine updating the Z coordinate of the 3rd element in an array of a million objects.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#29

Post by gameswithgo »

mrguyorama wrote: post #25
miohtama wrote: post #16

BLOSC already does this with software. http://blosc.org/ The sales pitch is "faster than memcpy." Fetch data from RAM, decompress it in L1,2,3 caches and run operations on the data. Some very nice benchmarks available.

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.

Re: CRAM: Efficient Hardware-Based Memory Compression for Bandwidth Enhancement

#30

Post by gameswithgo »

hinkley wrote: post #28
js8 wrote: post #4

I wonder how it would fare compared to "software-only" solution, that is re-architecturing your algorithm to work with compressed data directly. For example, consider an analytical engine going over values in a column of a database to sum it together. To increase the bandwidth, you can consider compressing the values (for example, with some form of Huffman encoding), and you have two options: 1. Decompress the values…

You glossing over the ugly truth here. Structured data and mutable data don't respond well to the type of operations you're talking about, and that is most of the interesting data in most programs. Most data requires random access to the middle, which is something compression is usually very bad at doing cheaply. You would have to leave boundary markers which eats into your size and speed advantage. Updating a record…

>Most data requires random access to the middle,

In domains where people need speed they are pretty clever at arranging to not need that.

Post reply on HN