[infinispan-dev] CHM or CHMv8?

Fri Apr 19 06:10:54 EDT 2013

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 :)

But I don't think that's going to yield any difference, because all the
copy-on-write in CHMV8 adds is a few volatile reads -  and volatile reads
are more or less free on x86.

> >
> >
> >
> >
> > 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
> _______________________________________________
> 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/77d3f178/attachment.html 