[infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

We also have been toying with the idea to hash each key only once,
instead of both with the consistent hash (to assign the node owner)
and once in the CHM backing the datacontainer.
I doubt we need the datacontainer to implement Map at all, but at
least if we go this way we don't want the hash to be affected by the
VM instance or different nodes won't agree on the expected owner ;-)

Also there where reports of it having a very bad impact on
performance, I'm not sure if they where resolved yet, or are going to
be resolved at all as it was important for security reasons.


On 22 April 2013 12:19, Dan Berindei <dan.berindei at gmail.com> wrote:
> Right. If we have anywhere a map that's initialized from a single thread and
> then accessed only for reading from many threads, it probably makes sense to
> use a HashMap and wrap it in an UnmodifiableMap. But if it can be written
> from multiple threads as well, I think we should use a CHMV8.
>
> BTW, the HashMap implementation in OpenJDK 1.7 seems to have some
> anti-collision features (a VM-dependent hash code generator for Strings),
> but our version of CHMV8 doesn't. Perhaps we need to upgrade to the latest
> CHMV8 version?
>
>
>
> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
>>
>> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
>> > On 19 April 2013 13:52, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> >>> On 19 April 2013 11:10, Dan Berindei <dan.berindei at gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
>> >>>> <sanne at infinispan.org>
>> >>>> wrote:
>> >>>>>
>> >>>>> On 19 April 2013 10:37, Dan Berindei <dan.berindei at gmail.com> wrote:
>> >>>>>> Testing mixed read/write performance with capacity 100000, keys
>> >>>>>> 300000,
>> >>>>>> concurrency level 32, threads 12, read:write ratio 99:1
>> >>>>>> Container CHM           Ops/s 5178894.77  Gets/s 5127105.82  Puts/s
>> >>>>>> 51788.95  HitRatio      86.23  Size     177848  stdDev   60896.42
>> >>>>>> Container CHMV8         Ops/s 5768824.37  Gets/s 5711136.13  Puts/s
>> >>>>>> 57688.24  HitRatio      84.72  Size     171964  stdDev   60249.99
>> >>>>>
>> >>>>> Nice, thanks.
>> >>>>>>
>> >>>>>> The test is probably limited by the 1% writes, but I think it does
>> >>>>>> show
>> >>>>>> that
>> >>>>>> reads in CHMV8 are not slower than reads in OpenJDK7's CHM.
>> >>>>>> I haven't measured it, but the memory footprint should also be
>> >>>>>> better,
>> >>>>>> because it doesn't use segments any more.
>> >>>>>>
>> >>>>>> AFAIK the memoryCHMV8 also uses copy-on-write at the bucket level,
>> >>>>>> but
>> >>>>>> we
>> >>>>>> could definitely do a pure read test with a HashMap to see how big
>> >>>>>> the
>> >>>>>> performance difference is.
>> >>>>>
>> >>>>> By copy-on-write I didn't mean on the single elements, but on the
>> >>>>> whole map instance:
>> >>>>>
>> >>>>> private volatile HashMap configuration;
>> >>>>>
>> >>>>> synchronized addConfigurationProperty(String, String) {
>> >>>>>        HashMap newcopy = new HashMap( configuration ):
>> >>>>>        newcopy.put(..);
>> >>>>>        configuration = newcopy;
>> >>>>> }
>> >>>>>
>> >>>>> Of course that is never going to scale for writes, but if writes
>> >>>>> stop
>> >>>>> at runtime after all services are started I would expect that the
>> >>>>> simplicity of the non-threadsafe HashMap should have some benefit
>> >>>>> over
>> >>>>> CHM{whatever}, or it would have been removed already?
>> >>>>>
>> >>>>
>> >>>> Right, we should be able to tell whether that's worth doing with a
>> >>>> pure read
>> >>>> test with a CHMV8 and a HashMap :)
>> >>>
>> >>> IFF you find out CHMV8 is as good as HashMap for read only, you have
>> >>> two options:
>> >>>    - ask the JDK team to drop the HashMap code as it's no longer
>> >>> needed
>> >>>    - fix your benchmark :-P
>> >>>
>> >>> In other words, I'd consider it highly surprising and suspicious
>> >>> (still interesting though!)
>> >>
>> >> It's not as surprising as you think.  On x86, volatile reads are the
>> >> same as regular reads (not counting some possible reordering magic).
>> >> So
>> >> if a CHM read is a hash, an array access, and a list traversal, and so
>> >> is HM (and I believe this is true though I'd have to review the code
>> >> again to be sure), I'd expect very similar execution performance on
>> >> read.  I think some of the anti-collision features in V8 might come
>> >> into
>> >> play under some circumstances though which might affect performance in
>> >> a
>> >> negative way (wrt the constant big-O component) but overall in a
>> >> positive way (by turning the linear big-O component into a logarithmic
>> >> one).
>> >
>> > Thanks David. I know about the cost of a volatile read, what I'm
>> > referring to
>> > is that I would expect the non-concurrent Maps to generally contain some
>> > simpler code than a conccurrent one. If this was not the case,
>> > why would any JDK team maintain two different implementations?
>> > That's why I would consider it surprising if it turned out that the
>> > CHMV8 was
>> > superior over a regular one on all fronts: there certainly is some
>> > scenario in which the regular one would be a more appropriate choice,
>> > which directly proofs that blindly replacing all usages in a large
>> > project
>> > is not optimal. Of course, it might be close to optimal..
>>
>> You are right, it is not superior on all fronts.  It is definitely
>> similar in terms of read, but writes will have a substantially higher
>> cost, involving (at the very least) multiple volatile writes which are
>> orders of magnitude more expensive than normal writes (on Intel they
>> have the costly impact of memory fence instructions).  So I don't think
>> anyone will want to drop HashMap any time soon. :-)
>>
>> --
>> - DML
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev