On 19 April 2013 13:52, David M. Lloyd <[email protected]> wrote: > On 04/19/2013 05:17 AM, Sanne Grinovero wrote: >> On 19 April 2013 11:10, Dan Berindei <[email protected]> wrote: >>> >>> >>> >>> 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 :) >> >> IFF you find out CHMV8 is as good as HashMap for read only, you have >> two options: >> - ask the JDK team to drop the HashMap code as it's no longer needed >> - fix your benchmark :-P >> >> In other words, I'd consider it highly surprising and suspicious >> (still interesting though!) > > It's not as surprising as you think. On x86, volatile reads are the > same as regular reads (not counting some possible reordering magic). So > if a CHM read is a hash, an array access, and a list traversal, and so > is HM (and I believe this is true though I'd have to review the code > again to be sure), I'd expect very similar execution performance on > read. I think some of the anti-collision features in V8 might come into > play under some circumstances though which might affect performance in a > negative way (wrt the constant big-O component) but overall in a > positive way (by turning the linear big-O component into a logarithmic one).
Thanks David. I know about the cost of a volatile read, what I'm referring to is that I would expect the non-concurrent Maps to generally contain some simpler code than a conccurrent one. If this was not the case, why would any JDK team maintain two different implementations? That's why I would consider it surprising if it turned out that the CHMV8 was superior over a regular one on all fronts: there certainly is some scenario in which the regular one would be a more appropriate choice, which directly proofs that blindly replacing all usages in a large project is not optimal. Of course, it might be close to optimal.. Sanne > > -- > - 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
