Re: [infinispan-dev] Faster LRU

On Mon, Jul 11, 2011 at 7:29 PM, Vladimir Blagojevic wrote: > On 11-07-08 5:44 AM, Dan Berindei wrote: >> >> I haven't run the tests with concurrency level 512, as the total >> number of threads is only 100, but I suspect the old LRU still won't >> catch up with the new LRU's performance. >> >> It

Re: [infinispan-dev] Faster LRU

On 11-07-08 5:44 AM, Dan Berindei wrote: > I haven't run the tests with concurrency level 512, as the total > number of threads is only 100, but I suspect the old LRU still won't > catch up with the new LRU's performance. > > It's interesting that in the writeOnMiss test the new LRU performance > d

Re: [infinispan-dev] Faster LRU

Yeah, nice work guys. :) On 11 Jul 2011, at 17:10, Sanne Grinovero wrote: > Amazing, congratulations Vladimir & Dan! > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Mani

Re: [infinispan-dev] Faster LRU

Amazing, congratulations Vladimir & Dan! ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Faster LRU

On Fri, Jul 8, 2011 at 12:44 PM, Dan Berindei wrote: > > It's interesting that in the writeOnMiss test the new LRU performance > dropped when I increased the concurrency level from 32 to 128. I think > it might be because the eviction.thresholdExpired() check in > BCHM.attemptEviction() is done wi

Re: [infinispan-dev] Faster LRU

Dan, Great work, why not update my forked tree https://github.com/vblagoje/infinispan/tree/t_bchm with your work as explained in section "Multi-step coordination between developers using forked repositories" from https://docs.jboss.org/author/display/ISPN/Contributing+-+Source+Control And the

Re: [infinispan-dev] Faster LRU

On Fri, Jul 8, 2011 at 2:53 AM, Dan Berindei wrote: > I've updated pull #414 > (https://github.com/infinispan/infinispan/pull/414) to work on top of > Vladimir's pull request, in case you want to have a look. You might > want to adjust the number of keys and/or disable some of the options > in the

Re: [infinispan-dev] Faster LRU

On Thu, Jul 7, 2011 at 1:21 PM, Manik Surtani wrote: > I think we leave the old LRU as LRU_OLD and mark it as deprecated. I for one am against keeping the old policy around, as the new LRU policy implements exactly the same algorithm only in O(1) instead of O(n). It would have made sense to keep

Re: [infinispan-dev] Faster LRU

On 11-07-07 6:21 AM, Manik Surtani wrote: > I think we leave the old LRU as LRU_OLD and mark it as deprecated. > > Vladimir, does this apply to LIRS as well? No, not LIRS, this was LRU optimization overlooked from the beginning :-) ___ infinispan-dev mai

Re: [infinispan-dev] Faster LRU

I think we leave the old LRU as LRU_OLD and mark it as deprecated. Vladimir, does this apply to LIRS as well? On 6 Jul 2011, at 21:08, Vladimir Blagojevic wrote: > No :-) We can leave it, it all depends on how many more CR cycles we have > before Final release to field test new LRU! > > On

Re: [infinispan-dev] Faster LRU

No :-) We can leave it, it all depends on how many more CR cycles we have before Final release to field test new LRU! On 11-07-06 2:46 PM, Sanne Grinovero wrote: Awesome! Are you really sure about eradicating the old implementation? Cheers, Sanne On 6 Jul 2011 19:39, "Vladimir Blagojevic"

Re: [infinispan-dev] Faster LRU

Awesome! Are you really sure about eradicating the old implementation? Cheers, Sanne On 6 Jul 2011 19:39, "Vladimir Blagojevic" wrote: > Hey, > > Ok I've issued a pull request. Please review it > https://github.com/infinispan/infinispan/pull/418 > I am very happy with performance increase observe

Re: [infinispan-dev] Faster LRU

Hey, Ok I've issued a pull request. Please review it https://github.com/infinispan/infinispan/pull/418 I am very happy with performance increase observed in new LRU. It significantly beats synchronized Map and performance is very close to ConcurrentHashMap itself. I ran tests overnight for 12 h

Re: [infinispan-dev] Faster LRU

On Tue, Jul 5, 2011 at 7:47 PM, Alex Kluge wrote: > Hi, > > I have a completely in-line limit on the cache entries built on a clock > cache that is an approximation to an LRU cache, and is extremely fast > (O(1)). It is not a strick LRU, but chooses a not recently used item for > removal. I'll

Re: [infinispan-dev] Faster LRU

On 11-07-05 12:47 PM, Alex Kluge wrote: Hi, I have a completely in-line limit on the cache entries built on a clock cache that is an approximation to an LRU cache, and is extremely fast (O(1)). It is not a strick LRU, but chooses a not recently used item for removal. I'll provide some more

Re: [infinispan-dev] Faster LRU

On 11-07-05 4:58 PM, Dan Berindei wrote: > +1 Vladimir, I had a similar idea to implement a BCHM segment entirely > using a single LinkedHashMap - obviously that requires a lot more work > to integrate with the existing BCHM then using a LHM inside the > eviction policy, but it should also be more

Re: [infinispan-dev] Faster LRU

On Tue, Jul 5, 2011 at 7:23 PM, Vladimir Blagojevic wrote: > Hey guys, > > In the past few days I've look around how to squeeze every bit of > performance out of BCHM and particularly our LRU impl. What I did not > like about current LRU is that a search for an element in the queue is > not consta

Re: [infinispan-dev] Faster LRU

ote: From: Vladimir Blagojevic Subject: [infinispan-dev] Faster LRU To: "infinispan -Dev List" Date: Tuesday, July 5, 2011, 11:23 AM Hey guys, In the past few days I've look around how to squeeze every bit of performance out of BCHM and particularly our LRU impl. What I did not like

[infinispan-dev] Faster LRU

Hey guys, In the past few days I've look around how to squeeze every bit of performance out of BCHM and particularly our LRU impl. What I did not like about current LRU is that a search for an element in the queue is not constant time operation but requires full queue traversal if we need to f