On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
On 19 April 2013 11:10, Dan Berindei <dan.berindei(a)gmail.com>
wrote:
>
>
>
> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <sanne(a)infinispan.org>
> wrote:
>>
>> On 19 April 2013 10:37, Dan Berindei <dan.berindei(a)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