On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <[email protected]>wrote:
> On 19 April 2013 10:37, Dan Berindei <[email protected]> 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 <[email protected]> > > 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" <[email protected]> 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 < > [email protected]> > >>> 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 > >>>> [email protected] > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> [email protected] > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
