[infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

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?

Sanne


>
>
>
>
> 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
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev