TinyLFU: A Highly Efficient Cache Admission Policy · HackerPapers discussions

TinyLFU: A Highly Efficient Cache Admission Policy — HN submission

Sat, 01 Oct 2022 21:05:19 GMT

TinyLFU: A Highly Efficient Cache Admission Policy

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — mentioned by thomasmg

Wed, 11 Aug 2021 08:30:56 GMT

If you need the ability to remove entries, then I would consider the counting Bloom filter (which is simpler, but needs more space), and the cuckoo filter. But you do need to be a bit careful as both can overflow if you are unlucky, or if you add too many entries. In which case you would have to re-build them. So better be prepared for this case, or prevent overflowing the filters by using a cascade of filters. Some clever cache implementations internally use special kinds of Bloom filters, e.g. the Caffeine cache (Java) uses TinyLFU, which "builds upon Bloom filter theory" (from the abstract…

Paper and discussion history. A mention is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — mentioned by T0pH4t

Thu, 27 Aug 2020 23:44:13 GMT

Maybe also consider tinylfu (https://arxiv.org/abs/1512.00727). I've implemented the windowed version with segmented caches and it works really well. Though it is a much more complicated implementation.

Paper and discussion history. A mention is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — mentioned by karlmcguire

Wed, 05 Jun 2019 14:32:30 GMT

Thanks for writing this. I'd love to hear your input on a possible application for this. I'm not sure if you're aware, but Counting Bloom Filters are useful as space efficient counters in LFU cache admission/eviction [1]. I'm wondering if bloom clocks would be a good data structure for a space efficient LRU admission/eviction. Full LRU uses a linked list and sampled LRU just uses random sampling, but my intuition is that bloom clocks might perform similarly or better than sampled LRU... The difficult part will be dealing with concurrency. I suppose it'd be easy to treat threads as "nodes"…

Paper and discussion history. A mention is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — HN submission

Fri, 25 May 2018 14:30:33 GMT

TinyLFU: A Highly Efficient Cache Admission Policy

3 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — mentioned by NovaX

Sun, 24 Apr 2016 02:53:14 GMT

This is sometimes referred to as the "admission policy" of a cache and can have a large effect at increasing the hit ratio. Most policies try to minimize the impact of low frequency items. For example SLRU uses a small probation space that promotes to a protected region if re-accessed. This allows quickly discarding low frequent items. ARC uses an adaptive version of this idea. LIRS uses a very small region (HIR) that promotes to a large region (LIR) based in the inter-reference period. This allows it to discard many new arrivals by using a large number of ghosts to retain usage history.…

Paper and discussion history. A mention is not an endorsement.

TinyLFU: A Highly Efficient Cache Admission Policy — mentioned by NovaX

Fri, 29 Jan 2016 17:24:29 GMT

TinyLFU+FIFO is in the simulator (https://github.com/ben-manes/caffeine/wiki/Simulator). However, you'd probably also want the window cache to correct the deficiency outlined in the updated paper (http://arxiv.org/pdf/1512.00727.pdf). A FIFO version with that isn't in the simulator, but would be easy to add. mutli1 trace - W-TinyLFU: 55.6% - TinyLFU+Random: 53.8% - TinyLFU+FIFO: 48.6% - TinyLFU+LRU: 54.8% - FIFO: 41.0% - LRU: 46.7% FIFO's poor choice of a victim has a big impact, so it doesn't seem promising. A random policy looks like an attractive fit, though.

Paper and discussion history. A mention is not an endorsement.