On 1/19/12 12:03 PM, Manik Surtani wrote: > All looking very good, people. Bela, feel like putting Table into NAKACK and > 3.0.3? ;)
Definitely not in NAKACK, it will be in NAKACK2 in 3.1. Once this has been running in production for a year or so, we can rename it to NAKACK. Remember, NakReceiverWindow might not be the fastest class around, but it's very stable and *correct*, and has been around for 12+ years... :-) If my experiments with NAKACK2 in 3.1 prove successful and I'm done sooner than expected, then, yes, I can backport it to 3.0.3 (or 3.0.4). I'd prefer to have Sanne run a test with the experimental 3.1 first though, so we can see if this makes a difference at all... > On 19 Jan 2012, at 16:29, Bela Ban wrote: > >> >> >> On 1/19/12 11:45 AM, Sanne Grinovero wrote: >>> On 19 January 2012 09:59, Bela Ban<b...@redhat.com> wrote: >>>> It would be interesting to see the numbers with bbc128, which makes >>>> sending a bit faster. I'd expect to see more writes and less reads, >>>> compared to their relative numbers. >>> >>> Ok, done. This is the same Infinispan build, but using JGroups bbc128: >>> >>> Done 880,969,860 transactional operations in 24.71 minutes using >>> 5.1.0-SNAPSHOT >>> 875,033,689 reads and 5,936,171 writes >>> Reads / second: 590,216 >>> Writes/ second: 4,003 >> >> >> OK, thanks. Not as dramatic though as the change in 23a031e... >> >> >>> Looks like a bit slower - confirming the figures I had two days ago. >>> Anyway my purpose with the comparison was just to proof the latest >>> patches in Infinispan where going in the correct direction, so I'm >>> intentionally not changing JGroups versions yet. >>> >>>> BTW: I'm done with my implementation of Table, and the numbers look >>>> really impressive ! It is about the same as RingBuffer for smaller >>>> insertions (5 million), but for 50 million the number stays about the >>>> same (insertions and removals per second). For smaller numbers, Table is >>>> ca 4 times *faster* than NakReceiverWindow. >>>> >>>> I still want to add more tests for Table (copy and convert the ones for >>>> RingBuffer), and then switch NAKACK2 over from RingBuffer to Table. I'm >>>> very curious to see the perf numbers after that change ! >>>> >>>> Next comes passing up of entire bundles, this should also make a big >>>> difference ! >>>> Exiting times, cheers ! >>> >>> If you commit it on an experimental branch, I'll give it a preview run .. >> >> The branch is JGRP-1396-2, the class is Table. There is a stress test >> called TableStressTest (you can compare it to >> NakReceiverWindowStressTest and RingBufferStressTest). >> >> >> -- >> Bela Ban >> Lead JGroups (http://www.jgroups.org) >> JBoss / Red Hat >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > ma...@jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Bela Ban Lead JGroups (http://www.jgroups.org) JBoss / Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev