<div dir="ltr"><div>Right. If we have anywhere a map that's initialized from a single thread and then accessed only for reading from many threads, it probably makes sense to use a HashMap and wrap it in an UnmodifiableMap. But if it can be written from multiple threads as well, I think we should use a CHMV8.<br>
<br></div>BTW, the HashMap implementation in OpenJDK 1.7 seems to have some anti-collision features (a VM-dependent hash code generator for Strings), but our version of CHMV8 doesn't. Perhaps we need to upgrade to the latest CHMV8 version?<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/19/2013 08:22 AM, Sanne Grinovero wrote:<br>
> On 19 April 2013 13:52, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br>
>> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:<br>
>>> On 19 April 2013 11:10, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> On 19 April 2013 10:37, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
>>>>>> Testing mixed read/write performance with capacity 100000, keys 300000,<br>
>>>>>> concurrency level 32, threads 12, read:write ratio 99:1<br>
>>>>>> Container CHM Ops/s 5178894.77 Gets/s 5127105.82 Puts/s<br>
>>>>>> 51788.95 HitRatio 86.23 Size 177848 stdDev 60896.42<br>
>>>>>> Container CHMV8 Ops/s 5768824.37 Gets/s 5711136.13 Puts/s<br>
>>>>>> 57688.24 HitRatio 84.72 Size 171964 stdDev 60249.99<br>
>>>>><br>
>>>>> Nice, thanks.<br>
>>>>>><br>
>>>>>> The test is probably limited by the 1% writes, but I think it does show<br>
>>>>>> that<br>
>>>>>> reads in CHMV8 are not slower than reads in OpenJDK7's CHM.<br>
>>>>>> I haven't measured it, but the memory footprint should also be better,<br>
>>>>>> because it doesn't use segments any more.<br>
>>>>>><br>
>>>>>> AFAIK the memoryCHMV8 also uses copy-on-write at the bucket level, but<br>
>>>>>> we<br>
>>>>>> could definitely do a pure read test with a HashMap to see how big the<br>
>>>>>> performance difference is.<br>
>>>>><br>
>>>>> By copy-on-write I didn't mean on the single elements, but on the<br>
>>>>> whole map instance:<br>
>>>>><br>
>>>>> private volatile HashMap configuration;<br>
>>>>><br>
>>>>> synchronized addConfigurationProperty(String, String) {<br>
>>>>> HashMap newcopy = new HashMap( configuration ):<br>
>>>>> newcopy.put(..);<br>
>>>>> configuration = newcopy;<br>
>>>>> }<br>
>>>>><br>
>>>>> Of course that is never going to scale for writes, but if writes stop<br>
>>>>> at runtime after all services are started I would expect that the<br>
>>>>> simplicity of the non-threadsafe HashMap should have some benefit over<br>
>>>>> CHM{whatever}, or it would have been removed already?<br>
>>>>><br>
>>>><br>
>>>> Right, we should be able to tell whether that's worth doing with a pure read<br>
>>>> test with a CHMV8 and a HashMap :)<br>
>>><br>
>>> IFF you find out CHMV8 is as good as HashMap for read only, you have<br>
>>> two options:<br>
>>> - ask the JDK team to drop the HashMap code as it's no longer needed<br>
>>> - fix your benchmark :-P<br>
>>><br>
>>> In other words, I'd consider it highly surprising and suspicious<br>
>>> (still interesting though!)<br>
>><br>
>> It's not as surprising as you think. On x86, volatile reads are the<br>
>> same as regular reads (not counting some possible reordering magic). So<br>
>> if a CHM read is a hash, an array access, and a list traversal, and so<br>
>> is HM (and I believe this is true though I'd have to review the code<br>
>> again to be sure), I'd expect very similar execution performance on<br>
>> read. I think some of the anti-collision features in V8 might come into<br>
>> play under some circumstances though which might affect performance in a<br>
>> negative way (wrt the constant big-O component) but overall in a<br>
>> positive way (by turning the linear big-O component into a logarithmic one).<br>
><br>
> Thanks David. I know about the cost of a volatile read, what I'm referring to<br>
> is that I would expect the non-concurrent Maps to generally contain some<br>
> simpler code than a conccurrent one. If this was not the case,<br>
> why would any JDK team maintain two different implementations?<br>
> That's why I would consider it surprising if it turned out that the CHMV8 was<br>
> superior over a regular one on all fronts: there certainly is some<br>
> scenario in which the regular one would be a more appropriate choice,<br>
> which directly proofs that blindly replacing all usages in a large project<br>
> is not optimal. Of course, it might be close to optimal..<br>
<br>
</div></div>You are right, it is not superior on all fronts. It is definitely<br>
similar in terms of read, but writes will have a substantially higher<br>
cost, involving (at the very least) multiple volatile writes which are<br>
orders of magnitude more expensive than normal writes (on Intel they<br>
have the costly impact of memory fence instructions). So I don't think<br>
anyone will want to drop HashMap any time soon. :-)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
- DML<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>