[infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

On 19 April 2013 13:52, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> On 19 April 2013 11:10, Dan Berindei <dan.berindei at gmail.com> wrote:
>>>
>>>
>>>
>>> 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 :)
>>
>> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev