[infinispan-dev] CHM or CHMv8?

[Dan Berindei]

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

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.




On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero <sanne at infinispan.org>wrote:

> Why not. Only doubt I'd have is that other usages of the CHM are - I guess
> - services registry and similar configuration tools, for which write
> performance is irrelevant: your test measured puts, are there drawbacks on
> gets or memory usage?
>
> Recently you changed all (most?) CHM creations to use a consistent
> factory, maybe we could improve on that by actually using a couple of
> factories which differentiate on the intended usage of the CHM: for example
> some maps who change very infrequently - mostly during boot or
> reconfiguration, maybe even topology change - could be better served by a
> non concurrent structure using copy-on-wrtite.
>
> Sanne
> On 19 Apr 2013 08:48, "Dan Berindei" <dan.berindei at gmail.com> wrote:
>
>> +1 to make CHMv8 the default on JDK6 and JDK7
>>
>> But I'm not convinced we should make it the default for JDK8 - even
>> though we don't know exactly what we're getting with the JDK's
>> implementation.
>>
>>
>> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:
>>
>>> On 04/18/2013 09:35 PM, Manik Surtani wrote:
>>> > Guys,
>>> >
>>> > Based on some recent micro benchmarks I've been doing, I've seen:
>>> >
>>> > MapStressTest configuration: capacity 100000, test running time 60
>>> seconds
>>> > Testing mixed read/write performance with capacity 100,000, keys
>>> 300,000, concurrency level 32, threads 12, read:write ratio 0:1
>>> > Container CHM           Ops/s 21,165,771.67  Gets/s       0.00  Puts/s
>>> 21,165,771.67  HitRatio     100.00  Size    262,682  stdDev 77,540.73
>>> > Container CHMV8         Ops/s 33,513,807.09  Gets/s       0.00  Puts/s
>>> 33,513,807.09  HitRatio     100.00  Size    262,682  stdDev 77,540.73
>>> >
>>> > So under high concurrency (12 threads, on my workstation with 12
>>> hardware threads - so all threads are always working), we see that
>>> Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
>>> implementation when doing puts.
>>> >
>>> > We use a fair number of CHMs all over Infinispan's codebase.  By
>>> default, these are all JDK-provided CHMs.  But we have the option to switch
>>> to our CHMv8 implementation by passing in
>>> -Dinfinispan.unsafe.allow_jdk8_chm=true.
>>> >
>>> > The question is, should this be the default?  Thoughts, opinions?
>>>
>>> The JDK's concurrency code - especially CHM - changes all the time.
>>> You'd be very well-served, in my opinion, to go with something like
>>> CHMv8 just because you could be so much more sure that you'll have more
>>> consistent (and possibly better, but definitely more consistent)
>>> performance across all JVMs, instead of being at the mercy of whatever
>>> particular implementation happens to run on whatever JVM.
>>>
>>>
>>> --
>>> - 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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130419/5878b052/attachment.html