We will still have a division in the consistent hash, because the "number
of segments" in some ways replaces . We just didn't add it to the HotRod
protocol yet...
I have thought about replacing division, and I was considering 2 options:
1. Hide the power of 2 restriction in the consistent hash implementation -
allow the user to specify any number of segments, but round it up
internally.
2. Compute the multiplicative inverse of the number of segments and use
multiplication instead - multiplication should be just as fast as addition
on modern machines.
However, the division didn't particularly stick out as a hotspot back when
I implemented DefaultConsistentHash, so I didn't pursue it further.
Cheers
Dan
On Thu, Aug 29, 2013 at 5:29 PM, Manik Surtani <msurtani(a)redhat.com> wrote:
Pls ignore. I've just been informed that hash space is to be
dropped from
the protocol anyway.
On 29 Aug 2013, at 13:35, Manik Surtani <msurtani(a)redhat.com> wrote:
> The Hot Rod protocol current passes the size of the hash space used to
clients, so that clients are able to create a consistent hash and perform
smart routing.
>
>
https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.0...
>
https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.2...
>
> However there are no rules as to what this hash space is, and this
forces clients to use the remainder operation when performing modular
arithmetic. This has been proven to be inefficient [1] [2] [3], and can be
greatly improved if we made a simple assumption that the hash space will
always be a power of two.
>
> Perhaps something we can add in v1.3 of the protocol, so that clients
talking to a server using Hot Rod 1.3 can make the assumption that the hash
space is a power of 2?
>
> WDYT?
>
> - Manik
>
>
> [1]
http://dhruba.name/2011/07/12/performance-pattern-modulo-and-powers-of-two/
> [2]
http://scicomp.stackexchange.com/questions/187/why-is-division-so-much-mo...
> [3]
http://disruptor.googlecode.com/files/Disruptor-1.0.pdf (Page 5,
last paragraph)
>
>
--
Manik Surtani
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev