New Linux tech compresses memory in RAM, as RAM, for 452x speedup — new CRAM method offers giant boost to compressed memory reads

4 days ago by inari to c/linux

The new method allows access using standard memory semantics instead of as a block device, drastically improving performance.
load all comments
okamiueru 101 points 4 days ago

Title is a bit misleading, and I think intentionally, which kinda irks me. It isn't a 400x speedup of RAM by means of compression. If I understood correctly, it's 400x speedup compared to disk read for swap.

Please correct me if I'm wrong here. I'd love some positive news from the IT world that isn't depressive. (edit: I implied this wasn't. It is. I'm just not sure of the actual impact)

path: 0 26226814, hotness: undefined, score: 101, children: 16
thingsiplay 25 points 4 days ago

I'm not sure if this is misleading at all. If anything, they should have mentioned compared to ZRAM. Title is incomplete, but I don't think it is intentionally misleading here. It just looks like they expect the reader to know CRAM is a replacement for ZRAM. The new compression method CRAM with over 400x speedup is compared to ZRAM method:

A new compression model, called CRAM, offers a different path to compression that avoids swap entirely by keeping the compressed data in memory, and it offers up to 452x the performance of ZRAM.

Because CRAM is stored in RAM and treated as RAM, with full cacheline/byte access, it can be accessed in a read-only fashion with little delay; just the cost of hardware-offloaded compression. As a result, CRAM "runs at DRAM speed," as the creator says in the slide above. While the graph already looks impressive, it's a logarithmic scale; CRAM, in the worst case, is doing 489 million operations per second versus ZRAM's 1.1 million. It's barely comparable.

Even when you enable writes, CRAM is still much faster than ZRAM; 5.4x in the worst tested case of 20% writes. That's a huge drop from the 452x read-only case, but keep your context; a 5.4x speedup is still titanic.

Is writes enabled CRAM / ZRAM common? If so, then the post title is definitely misleading.

path: 0 26226814 26227419, hotness: undefined, score: 25, children: 6
klankin 3 points 4 days ago

Yeah wait how would you have read only RAM?

Loaded on boot for the OS I suppose?

Probably nice for running TV boxes off even less RAM than they're already starved for lmao

path: 0 26226814 26227419 26236701, hotness: undefined, score: 3, children: 5
thingsiplay 1 point 3 days ago

Guess read only RAM becomes... ROM? :D I have no clue either. Maybe there are protected areas in the memory no program has write access to, so it is read only from perspective of the application. Searching the web doesn't help, because every link I clicked just explains the difference between ROM and RAM.

Hmm... when I think about Rust programming (which is true in C too probably), there are two types of locations our variables can assigned to: Stack and Heap. In example if you have a text string as a literal like "Version 1.0", that string is located in the Stack memory, because it is unchanging. The Heap gets all those content that can vary and arbitrary long, but its slower. So the Stack content is much smaller, faster and basically read only RAM area (if I understand this correctly). Maybe that is it?

path: 0 26226814 26227419 26236701 26240982, hotness: undefined, score: 1, children: 4
blackbrook 1 point 3 days ago

I'm drawing on some old memories here, so I could be mistaken, but I don't think the stack is read only, not in C anyway or in the underlying machine code. If it is faster it has to do with greater overhead needed managing the larger heap and perhaps being more efficient to push and pop with small offsets to a local stack frame vs large absolute addresses.

path: 0 26226814 26227419 26236701 26240982 26241528, hotness: undefined, score: 1, children: 3
thingsiplay 1 point 3 days ago

but I don’t think the stack is read only

I don't mean the stack is read only (edit: yes I meant that in my previous reply, but got confused myself, I actually never thought the entire stack being read only, I was only thinking about those specific variables and literal strings, sorry for confusion), but certain variables holding values that are only used to read and not change. In example you cannot change literals, therefore they are read only values. In example if you have a program that prints "Hello Lemmy", that string is a literal that cannot be altered, and it is found in the application itself, as part of the binary. That part maybe is marked as read only?

path: 0 26226814 26227419 26236701 26240982 26241528 26241643, hotness: undefined, score: 1, children: 2
blackbrook 1 point 3 days ago

Right, a stack that was itself read-only would be hard to use! :^D C definitely lets you modify the things in the stack. (Ah the fun of bugs where you accidentally overwrite other shit on the stack!) I don't know Rust, but it would not surprise me if Rust only had immutable things on the stack.

path: 0 26226814 26227419 26236701 26240982 26241528 26241643 26253061, hotness: undefined, score: 1, children: 1
linux
linux

@lemmy.ml

login for more options
68043
9435
5656

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

  • Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
  • No misinformation
  • No NSFW content
  • No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

go to feed...