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<bban(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
Lead JGroups (
http://www.jgroups.org)
JBoss / Red Hat