<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">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>
</div>Nice, thanks.<br>
<div class="im">><br>
> The test is probably limited by the 1% writes, but I think it does show 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 we<br>
> could definitely do a pure read test with a HashMap to see how big the<br>
> performance difference is.<br>
<br>
</div>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>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Right, we should be able to tell whether that's worth doing with a pure read test with a CHMV8 and a HashMap :)<br></div><div>
</div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
<br>
><br>
><br>
><br>
><br>
> On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
> wrote:<br>
>><br>
>> Why not. Only doubt I'd have is that other usages of the CHM are - I guess<br>
>> - services registry and similar configuration tools, for which write<br>
>> performance is irrelevant: your test measured puts, are there drawbacks on<br>
>> gets or memory usage?<br>
>><br>
>> Recently you changed all (most?) CHM creations to use a consistent<br>
>> factory, maybe we could improve on that by actually using a couple of<br>
>> factories which differentiate on the intended usage of the CHM: for example<br>
>> some maps who change very infrequently - mostly during boot or<br>
>> reconfiguration, maybe even topology change - could be better served by a<br>
>> non concurrent structure using copy-on-wrtite.<br>
>><br>
>> Sanne<br>
>><br>
>> On 19 Apr 2013 08:48, "Dan Berindei" <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
>>><br>
>>> +1 to make CHMv8 the default on JDK6 and JDK7<br>
>>><br>
>>> But I'm not convinced we should make it the default for JDK8 - even<br>
>>> though we don't know exactly what we're getting with the JDK's<br>
>>> implementation.<br>
>>><br>
>>><br>
>>> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On 04/18/2013 09:35 PM, Manik Surtani wrote:<br>
>>>> > Guys,<br>
>>>> ><br>
>>>> > Based on some recent micro benchmarks I've been doing, I've seen:<br>
>>>> ><br>
>>>> > MapStressTest configuration: capacity 100000, test running time 60<br>
>>>> > seconds<br>
>>>> > Testing mixed read/write performance with capacity 100,000, keys<br>
>>>> > 300,000, concurrency level 32, threads 12, read:write ratio 0:1<br>
>>>> > Container CHM Ops/s 21,165,771.67 Gets/s 0.00 Puts/s<br>
>>>> > 21,165,771.67 HitRatio 100.00 Size 262,682 stdDev 77,540.73<br>
>>>> > Container CHMV8 Ops/s 33,513,807.09 Gets/s 0.00 Puts/s<br>
>>>> > 33,513,807.09 HitRatio 100.00 Size 262,682 stdDev 77,540.73<br>
>>>> ><br>
>>>> > So under high concurrency (12 threads, on my workstation with 12<br>
>>>> > hardware threads - so all threads are always working), we see that<br>
>>>> > Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM<br>
>>>> > implementation when doing puts.<br>
>>>> ><br>
>>>> > We use a fair number of CHMs all over Infinispan's codebase. By<br>
>>>> > default, these are all JDK-provided CHMs. But we have the option to switch<br>
>>>> > to our CHMv8 implementation by passing in<br>
>>>> > -Dinfinispan.unsafe.allow_jdk8_chm=true.<br>
>>>> ><br>
>>>> > The question is, should this be the default? Thoughts, opinions?<br>
>>>><br>
>>>> The JDK's concurrency code - especially CHM - changes all the time.<br>
>>>> You'd be very well-served, in my opinion, to go with something like<br>
>>>> CHMv8 just because you could be so much more sure that you'll have more<br>
>>>> consistent (and possibly better, but definitely more consistent)<br>
>>>> performance across all JVMs, instead of being at the mercy of whatever<br>
>>>> particular implementation happens to run on whatever JVM.<br>
>>>><br>
>>>><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>
>>><br>
>>><br>
>>><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>
>><br>
>><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>
><br>
><br>
><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>
_______________________________________________<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></div>