Linux

The person who came up with this acronym is probably proud of their work lol

cram it all in there!

It's a little better than your read. The ~400x speedup is in comparison to using ZRAM, which, in very brief terms, compresses memory by creating an in-memory compressed block device and assigning that as your swap space. So your "swap" is actually a compressed chunk of RAM, not on disk.

This was significantly slower than normal memory access because page faulting when looking up something in memory then fetching from swap was, itself, expensive. Regardless of how fast that swap was. When your swap is on a storage device that overhead is comparatively tiny, but when it's just another chunk of memory suddenly it's what you're spending most of your time on.

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.

Let me use my Raspberry Pi 3b as a practical example of what @vithigar@lemmy.ca was explaining. I run PiHole + Unbound on the Raspberry Pi 3b, with 1GB of ram. The main killer for a little Pi 3b is reading and writing to the SD card. We want to avoid that as much as possible. Block lists get updated weekly, so that's no big deal, but there is still a lot of traffic information that is being kept track of. The solution is to load all of that into zram. As you can imagine, on a slow and resource constrained system like a Pi 3b, any performance enhancement has a huge impact. A 452x performance increase over ZRAM on a system that mostly lives on ZRAM is massive.

I am not entirely sure about this but I imagine that this is also massive news for live operating systems like Tails and Kali Live.

Could already do that with zram!

When I was in computer science in college back in the 1900s, they told us that the USSR was responsible for some of the best algorithms still in use at the time (both for RAM and CPU usage) because they just had less to work with.

Guess we're all in that boat now.

You know it's getting weird out there when Meta seems to be doing something that's actually useful.

This is still just a bandaid over running 10 copies of chromium for each electron app.

Necessity is the mother of invention.

That certainly seems to be a genre of article right now.

Cloudflare frees up 100TB of RAM by shrinking 1.1.1.1's DNS cache entries

MSI promises an EXPO ULL-like boost for your existing DDR5 memory

Microsoft vows to make Windows 11 fly on 8GB RAM amid memory shortage

Does it count as optimization? For supported hardware, it's certainly cool. But it's not making inefficient software better, it's making better use of the hardware.

I remember this trash:

I feel like zRAM showed up when prices were historically low

Too bad, this isn't happening as a kernel patch. Adding to that point:

The key detail is that CRAM is a hardware implementation of compression, meaning the logic is in the memory controller rather than in software, so it's not a pure software trick like ZRAM. However, it uses standard off-the-shelf DRAM and a normal memory bus, so no exotic modules or custom interfaces are required.

I remember an old DOS utility called Ram Doubler. Sadly it also halved the speed.