[infinispan-dev] Hash functions

[Bryan Grunow]

Yes, that's what I was thinking.

Thanks,

Bryan

-----Original Message-----
From: infinispan-dev-bounces at lists.jboss.org
[mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
Surtani
Sent: Wednesday, March 24, 2010 6:06 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Hash functions

It would be pluggable but one would need to keep in mind that if using
the remote client API (HotRod) with hash distribution aware smart
clients, clients would need knowledge of your hash function as well.

So I see the "pluggability" of this only being useful/practically
useable if your access pattern is embedded/p2p or non-smart remote
clients.

On 23 Mar 2010, at 20:31, Bryan Grunow wrote:

> This may have been stated somewhere but will the Hash function be
> configurable?  At least at the deployment level.  Not sure about at
the
> cache level.
> 
> I could see where different deployments might want different hash
> attributes.  E.g. spread vs. speed or CPU neutral behavior vs. spread,
> etc.
> 
> Bryan
> 
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org
> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Manik
> Surtani
> Sent: Tuesday, March 23, 2010 10:44 AM
> To: infinispan -Dev List
> Subject: [infinispan-dev] Hash functions
> 
> Some very early results,
> 
> 	http://pastie.org/883111
> 
> Only testing MurmurHash2 (endian-neutral variant which is 2x as slow
as
> the original algo) and SuperFastHash.  I haven't implemented FNV-1 as
> yet.
> 
> Some notes:
> 
> * Test was run over 100k random keys
> * Max size for a String and byte[] key set to 16.  Actual size is a
> random number between 1 and MaxSize.
> * Functions mainly implemented to handle byte[]'s.
> * Functions handle Strings by calling String.getBytes().  The bulk of
> the time spent in String keys is therefore attributed to
> String.getBytes().
> * Functions handle Object hashcodes by taking the int hashcode and
> creating a 4-element byte[] out of it.  Again, the bulk of the time
> spent here is in this conversion.
> * Keys generated before any measurements taken, a full cycle run to
warm
> up the hotspot compiler as well.
> 
> Looks like MurmurHash2, despite using the slower version to
accommodate
> CPU endian neutral behaviour, is winning in terms of distribution.
And
> by a fair way too.
> 
> For those interested in the test and the hash impls, have a look at
this
> (dependency on Apache commons-math):
> 
> 	http://pastie.org/883135
> 
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org





_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.