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