4 ms·
> 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
by habibur 5y ago
> 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.
- hiddencost 5y agoThey're working with petabytes of datab in ram. Terabytes per machine. Code size isn't significant by comparison.
- axiosgunnar 5y agoI 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)
- hiddencost 5y agoCombining 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 http://www.mattmahoney.net/dc/text.html
- jeffbee 5y agoCode 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.
- corty 5y agoDepending 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.