On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> On 19 April 2013 11:10, Dan Berindei <dan.berin...@gmail.com> wrote:
>>
>>
>>
>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <sa...@infinispan.org>
>> wrote:
>>>
>>> On 19 April 2013 10:37, Dan Berindei <dan.berin...@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).
--
- DML
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
