Hacker News Reader

Comment by habibur | Hacker News Reader

> we expect Ribbon filters to save several percent of RAM resources, with a tiny increase in CPU usage for some major storage systems.

I would have factored in the code size with it too.

View on HN

Depending on whether their CPU usage figures include waiting for memory accesses, any savings in RAM usage might be worth it: current systems do have a lot less memory bandwidth than CPU power, so it is preferable to compute more and load/store less. If their using less RAM also translates to using fewer loads/stores and more computations from registers (which they hint at), this optimisation might be a bigger win than it looks at first.

They're working with petabytes of datab in ram. Terabytes per machine. Code size isn't significant by comparison.

I assume he meant code size as in how much a developer would need to read to understand.

Basically using code size as a proxy for code complexity

(which is not always the case of course)

Combining the binary size with the compressed data size is fairly typical when measuring compression schemes. Otherwise you end up in situations where people game benchmarks.

E.g., from [0]:

Compressors are ranked by the compressed size of enwik9 (109 bytes) plus the size of a zip archive containing the decompresser.

[0] http://www.mattmahoney.net/dc/text.html

Code size, if it causes iTLB misses, is a problem. If a program has lots of hot code sparsely distributed that’s an opportunity for optimization. On the other hand I expect Facebook to have a handle on this issue, in light of their BOLT and general maturity of their tool chain.

Reply on news.ycombinator.com