Hacker News Reader

Comment by sema4hacker | Hacker News Reader

In the 70's when memory was always small and expensive, I had to keep things as packed and tight as possible. But now memory is so huge and cheap that it's been a long time since I had to worry about things like packing bits, which is incredibly bug-prone anyway.

View on HN

Cache is not huge. If you want good performance you need to keep your working set in cache. Sometimes that requires storing offsets (say 32-bit) rather than pointers. If you can also pack info into spare bits, all the better. Perhaps not everyone needs to care about this, but there are still reasons to care.

Indeed, you might have hundreds of GBs, or even TBs of memory, but caches are still (relatively) small. L1 is going to be in the order of 64k of memory!

Depending on what you're building, memory is still scarce. Of course in the past that was much more common, but even today just doubling memory doesn't always fly: Embedded is still not a land of plenty; and not every computational expensive task is a money earner, which might put you in a difficult spot when arguing with controlling about a bigger server or at least a memory upgrade.

Also: Caching.

I take it you never wrote code involving atomic pointers. Regardless of memory usage, a lot of platforms only provide single-word atomics (efficiently), making bitpacking crucial for lockfree algorithms.

A benefit for packing pointers is when the data needed is already packed-this will avoid a pointer reference.

Reply on news.ycombinator.com