Re: [infinispan-dev] CHM or CHMv8?

[Mircea Markus]

On 25 Apr 2013, at 12:49, Dan Berindei wrote:

> Yeah, I don't think you could extract the hash from the "cache of hashes" 
> without computing the hash in the first place...
> 
> My idea was to wrap the key in a KeyWithHash object and cache the hash there 
> (since we're looking up the same key in a lot of maps during a single 
> invocation).
My understanding of the problem Sanne tried to solve is the calculation of the 
hash of a key several times, in multiple interceptors, during a single 
operation/transaction. I don't think we should take it as far as keeping the 
hash together with the key. Also this is an optimisation so we shouldn't go out 
of our way in order to implement it.
> Sorry Galder, I forgot about your patch, but I still think we'd need a 
> wrapper for keys in order to cache the hash code even if we could define an 
> Equivalence function.


Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)





___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

Yeah, I don't think you could extract the hash from the "cache of hashes"
without computing the hash in the first place...

My idea was to wrap the key in a KeyWithHash object and cache the hash
there (since we're looking up the same key in a lot of maps during a single
invocation).

Sorry Galder, I forgot about your patch, but I still think we'd need a
wrapper for keys in order to cache the hash code even if we could define an
Equivalence function.




On Thu, Apr 25, 2013 at 2:27 PM, Sanne Grinovero wrote:

> On 25 April 2013 11:51, Galder Zamarreño  wrote:
> >
> > On Apr 22, 2013, at 3:09 PM, Dan Berindei 
> wrote:
> >
> >>
> >>
> >>
> >> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero 
> wrote:
> >> We also have been toying with the idea to hash each key only once,
> >> instead of both with the consistent hash (to assign the node owner)
> >> and once in the CHM backing the datacontainer.
> >> I doubt we need the datacontainer to implement Map at all, but at
> >> least if we go this way we don't want the hash to be affected by the
> >> VM instance or different nodes won't agree on the expected owner ;-)
> >>
> >>
> >> For consistent hashing it would probably be better to cache the hash
> after applying MurmurHash to it anyway. So we could in theory hack our
> CHMV8 to use a cached hash code computed with MurmurHash and a
> cluster-specific salt.
> >
> > ^ Rather than hacking CHMv8, better to provide an Equivalence function
> (which CHMv8 will have an instance variable of) for the keys which keeps
> the cache of hashes or something… once that work is committed, we can
> discuss further :)
>
> +1 to use your cool implementation. Don't like too much the sound of
> "cache the hashes or something", I didn't actually look at the code,
> but from gut feeling I would hope the Equivalence function to be
> stateless? We might be able to pass the to-be-reused hash as a
> parameter in primitive form.
>
> Sanne
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Galder Zamarreño]

On Apr 25, 2013, at 1:37 PM, Manik Surtani  wrote:

> 
> On 25 Apr 2013, at 11:41, Galder Zamarreño  wrote:
> 
>> So, in case anyone is itching to start on 3022 and 3023, hold on for a few 
>> days while I finish the work to include EquivalentCHMv8.
> 
> 3022 is already in.  The patch was trivial - change a default value in 
> ConcurrentMapFactory.  Once you finish EquivalentCHMv8, again, all you need 
> to do is change ConcurrentMapFactory again to use EquivalentCHMv8 instead of 
> CHMv8.

^ Ok, I'll have to rebase that. 

Btw, something coming up in the 2281 pull req: I'm changing 
ConcurrentMapFactory to be CollectionFactory to deal with other collections to 
be able to return normal hash maps or equivalent hash maps too, because once 
you allow a array based key, any collection that has a reference to a key (i.e. 
invocation context), must keep this in a equivalent collection too.

> 
> As a side point, as you implement EquivalentCHMv8, could you make sure it is 
> based on the latest CHMv8 impl from jsr166e:
> 
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?revision=1.100&view=markup
> 
> We should also include, in the comments, what revision of jsr166e's 
> implementation we're based on (e.g., 1.100 in the link above).

Great minds think alike :)

https://github.com/galderz/infinispan/blob/t_2281/core/src/main/java/org/infinispan/util/concurrent/jdk8backported/EquivalentConcurrentHashMapV8.java#L24

> 
> - M
> 
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
> 
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

On 25 Apr 2013, at 11:41, Galder Zamarreño  wrote:

> So, in case anyone is itching to start on 3022 and 3023, hold on for a few 
> days while I finish the work to include EquivalentCHMv8.

3022 is already in.  The patch was trivial - change a default value in 
ConcurrentMapFactory.  Once you finish EquivalentCHMv8, again, all you need to 
do is change ConcurrentMapFactory again to use EquivalentCHMv8 instead of CHMv8.

As a side point, as you implement EquivalentCHMv8, could you make sure it is 
based on the latest CHMv8 impl from jsr166e:

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?revision=1.100&view=markup

We should also include, in the comments, what revision of jsr166e's 
implementation we're based on (e.g., 1.100 in the link above).

- M

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

On 25 April 2013 11:51, Galder Zamarreño  wrote:
>
> On Apr 22, 2013, at 3:09 PM, Dan Berindei  wrote:
>
>>
>>
>>
>> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero  
>> wrote:
>> We also have been toying with the idea to hash each key only once,
>> instead of both with the consistent hash (to assign the node owner)
>> and once in the CHM backing the datacontainer.
>> I doubt we need the datacontainer to implement Map at all, but at
>> least if we go this way we don't want the hash to be affected by the
>> VM instance or different nodes won't agree on the expected owner ;-)
>>
>>
>> For consistent hashing it would probably be better to cache the hash after 
>> applying MurmurHash to it anyway. So we could in theory hack our CHMV8 to 
>> use a cached hash code computed with MurmurHash and a cluster-specific salt.
>
> ^ Rather than hacking CHMv8, better to provide an Equivalence function (which 
> CHMv8 will have an instance variable of) for the keys which keeps the cache 
> of hashes or something… once that work is committed, we can discuss further :)

+1 to use your cool implementation. Don't like too much the sound of
"cache the hashes or something", I didn't actually look at the code,
but from gut feeling I would hope the Equivalence function to be
stateless? We might be able to pass the to-be-reused hash as a
parameter in primitive form.

Sanne

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Galder Zamarreño]

On Apr 22, 2013, at 3:09 PM, Dan Berindei  wrote:

> 
> 
> 
> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero  wrote:
> We also have been toying with the idea to hash each key only once,
> instead of both with the consistent hash (to assign the node owner)
> and once in the CHM backing the datacontainer.
> I doubt we need the datacontainer to implement Map at all, but at
> least if we go this way we don't want the hash to be affected by the
> VM instance or different nodes won't agree on the expected owner ;-)
> 
> 
> For consistent hashing it would probably be better to cache the hash after 
> applying MurmurHash to it anyway. So we could in theory hack our CHMV8 to use 
> a cached hash code computed with MurmurHash and a cluster-specific salt.

^ Rather than hacking CHMv8, better to provide an Equivalence function (which 
CHMv8 will have an instance variable of) for the keys which keeps the cache of 
hashes or something… once that work is committed, we can discuss further :)

> 
>  
> Also there where reports of it having a very bad impact on
> performance, I'm not sure if they where resolved yet, or are going to
> be resolved at all as it was important for security reasons.
> 
> 
> I suspect most of the performance impact came from no longer using the cached 
> hash code in the String class. And since String.hashCode() isn't allowed to 
> change, that isn't going to change any time soon.
> 
>  
> 
> On 22 April 2013 12:19, Dan Berindei  wrote:
> > 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.
> >
> > 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?
> >
> >
> >
> > On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd 
> > wrote:
> >>
> >> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
> >> > On 19 April 2013 13:52, David M. Lloyd  wrote:
> >> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> >> >>> On 19 April 2013 11:10, Dan Berindei  wrote:
> >> 
> >> 
> >> 
> >>  On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
> >>  
> >>  wrote:
> >> >
> >> > On 19 April 2013 10:37, Dan Berindei  wrote:
> >> >> Testing mixed read/write performance with capacity 10, keys
> >> >> 30,
> >> >> 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 

Re: [infinispan-dev] CHM or CHMv8?

[Galder Zamarreño]

On Apr 22, 2013, at 2:33 PM, David M. Lloyd  wrote:

> AFAIK the JDK team is looking at dropping alternative hashing for 
> strings and instead going with the comparator-based collision resolution 
> once a bucket reaches a certain size.  I'm not sure how this is expected 
> to work for a map with multiple key types though.

^ Hmmm, I'm pretty sure I've seen something similar in CHMv8. Once it reaches 
certain size, tree-based bins are used, which check whether the entries are 
Comparable. In fact, I've accomodated this into Equivalence interface, so that 
we can provide a way to define whether a given key or value is comparable, i.e. 
for arrays.

Cheers,

> 
> On 04/22/2013 06:19 AM, Dan Berindei wrote:
>> 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.
>> 
>> 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?
>> 
>> 
>> 
>> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd > > wrote:
>> 
>>On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
>>> On 19 April 2013 13:52, David M. Lloyd >> wrote:
 On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> On 19 April 2013 11:10, Dan Berindei >> wrote:
>> 
>> 
>> 
>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
>>mailto:sa...@infinispan.org>>
>> wrote:
>>> 
>>> On 19 April 2013 10:37, Dan Berindei >> wrote:
 Testing mixed read/write performance with capacity 10,
>>keys 30,
 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
>>

Re: [infinispan-dev] CHM or CHMv8?

[Galder Zamarreño]

On Apr 22, 2013, at 1:37 PM, Sanne Grinovero  wrote:

> We also have been toying with the idea to hash each key only once,
> instead of both with the consistent hash (to assign the node owner)
> and once in the CHM backing the datacontainer.

^ With the new EquivalentCHMv8, I think we can make this happen quite easily, 
cos we provide a function that is used to calculate the hash of an object. 
Hence, we can think of a way to plug what you suggest there.

> I doubt we need the datacontainer to implement Map at all, but at
> least if we go this way we don't want the hash to be affected by the
> VM instance or different nodes won't agree on the expected owner ;-)
> 
> Also there where reports of it having a very bad impact on
> performance, I'm not sure if they where resolved yet, or are going to
> be resolved at all as it was important for security reasons.
> 
> 
> On 22 April 2013 12:19, Dan Berindei  wrote:
>> 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.
>> 
>> 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?
>> 
>> 
>> 
>> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd 
>> wrote:
>>> 
>>> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
 On 19 April 2013 13:52, David M. Lloyd  wrote:
> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> On 19 April 2013 11:10, Dan Berindei  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
>>> 
>>> wrote:
 
 On 19 April 2013 10:37, Dan Berindei  wrote:
> Testing mixed read/write performance with capacity 10, keys
> 30,
> 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 

Re: [infinispan-dev] CHM or CHMv8?

[Galder Zamarreño]

Just a heads up on this. As mentioned in another email, I've created a CHMv8 
version called EquivalentCHMv8 which allows equals/hashCode/toString calls on 
keys/values to be done via the new Equivalence interface, which allows even 
arrays to be used as key/values.

I originally planned to keep both CHMv8 and EquivalentCHMv8, but as Manik 
already suggested in another email, we should just keep EquivalentCHMv8. The 
changes are fairly minimal compared to CHMv8.

So, in case anyone is itching to start on 3022 and 3023, hold on for a few days 
while I finish the work to include EquivalentCHMv8.

Cheers,

On Apr 19, 2013, at 2:16 PM, Manik Surtani  wrote:

> Ok, I've created 
> 
> https://issues.jboss.org/browse/ISPN-3022
> 
> In fact, we should also re-implement the BoundedConcurrentHashMap - the basis 
> for LIRS and LRU eviction algorithms - to use techniques similar to CHMv8 
> rather than the old segment-based approach.  
> 
> https://issues.jboss.org/browse/ISPN-3023
> 
> Anyone has a few spare cycles - and is really good with complex concurrency 
> code - want to take this on?  ;)
> 
> - M
> 
> On 19 Apr 2013, at 09:06, Manik Surtani  wrote:
> 
>> 
>> On 19 Apr 2013, at 05:07, Sanne Grinovero  wrote:
>> 
>>> Why not. Only doubt I'd have is that other usages of the CHM are - I guess 
>>> - services registry and similar configuration tools, for which write 
>>> performance is irrelevant: your test measured puts, are there drawbacks on 
>>> gets or memory usage?
>>> 
>> See the original announcement on concurrency-interest by Doug Lea, and the 
>> subsequent comments.  The design is up here too.  One of the goals was to 
>> drastically reduce memory usage with CHMv8.
>> 
>> http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/8140
>> 
>> Interestingly, Netty uses a backported CHMv8 as well - apparently inspired 
>> by our inclusion of it in Infinispan.  ;)
>> 
>> https://github.com/netty/netty/issues/1052
>> 
>> -M
>> 
>> --
>> Manik Surtani
>> ma...@jboss.org
>> twitter.com/maniksurtani
>> 
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>> 
> 
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
> 
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero wrote:

> We also have been toying with the idea to hash each key only once,
> instead of both with the consistent hash (to assign the node owner)
> and once in the CHM backing the datacontainer.
> I doubt we need the datacontainer to implement Map at all, but at
> least if we go this way we don't want the hash to be affected by the
> VM instance or different nodes won't agree on the expected owner ;-)
>
>
For consistent hashing it would probably be better to cache the hash after
applying MurmurHash to it anyway. So we could in theory hack our CHMV8 to
use a cached hash code computed with MurmurHash and a cluster-specific salt.



> Also there where reports of it having a very bad impact on
> performance, I'm not sure if they where resolved yet, or are going to
> be resolved at all as it was important for security reasons.
>
>
I suspect most of the performance impact came from no longer using the
cached hash code in the String class. And since String.hashCode() isn't
allowed to change, that isn't going to change any time soon.



>
> On 22 April 2013 12:19, Dan Berindei  wrote:
> > 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.
> >
> > 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?
> >
> >
> >
> > On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd 
> > wrote:
> >>
> >> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
> >> > On 19 April 2013 13:52, David M. Lloyd 
> wrote:
> >> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> >> >>> On 19 April 2013 11:10, Dan Berindei 
> wrote:
> >> 
> >> 
> >> 
> >>  On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
> >>  
> >>  wrote:
> >> >
> >> > On 19 April 2013 10:37, Dan Berindei 
> wrote:
> >> >> Testing mixed read/write performance with capacity 10, keys
> >> >> 30,
> >> >> 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 o

Re: [infinispan-dev] CHM or CHMv8?

[Mircea Markus]

On 22 Apr 2013, at 13:37, Sanne Grinovero wrote:

> We also have been toying with the idea to hash each key only once,
> instead of both with the consistent hash (to assign the node owner)
> and once in the CHM backing the datacontainer.
these two computations would occur on two different nodes though: once where 
the request originated and remotely on the node where the key is kept. So it 
would only make sense for local and replicated caches,  which is not "the 
critical path". 
> I doubt we need the datacontainer to implement Map at all,
The DataContainer doesn't implement Map ATM.
> but at
> least if we go this way we don't want the hash to be affected by the
> VM instance or different nodes won't agree on the expected owner ;-)
> 
> Also there where reports of it having a very bad impact on
> performance, I'm not sure if they where resolved yet, or are going to
> be resolved at all as it was important for security reasons.
> 
> 
> On 22 April 2013 12:19, Dan Berindei  wrote:
>> 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.
>> 
>> 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?
>> 
>> 
>> 
>> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd 
>> wrote:
>>> 
>>> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
 On 19 April 2013 13:52, David M. Lloyd  wrote:
> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> On 19 April 2013 11:10, Dan Berindei  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
>>> 
>>> wrote:
 
 On 19 April 2013 10:37, Dan Berindei  wrote:
> Testing mixed read/write performance with capacity 10, keys
> 30,
> 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

Re: [infinispan-dev] CHM or CHMv8?

[David M. Lloyd]

AFAIK the JDK team is looking at dropping alternative hashing for 
strings and instead going with the comparator-based collision resolution 
once a bucket reaches a certain size.  I'm not sure how this is expected 
to work for a map with multiple key types though.

On 04/22/2013 06:19 AM, Dan Berindei wrote:
> 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.
>
> 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?
>
>
>
> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd  > wrote:
>
> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
>  > On 19 April 2013 13:52, David M. Lloyd  > wrote:
>  >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>  >>> On 19 April 2013 11:10, Dan Berindei  > wrote:
>  
>  
>  
>   On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
> mailto:sa...@infinispan.org>>
>   wrote:
>  >
>  > On 19 April 2013 10:37, Dan Berindei  > wrote:
>  >> Testing mixed read/write performance with capacity 10,
> keys 30,
>  >> 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,

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

On 22 Apr 2013, at 08:37, Sanne Grinovero  wrote:

> Also there where reports of it having a very bad impact on
> performance, I'm not sure if they where resolved yet, or are going to
> be resolved at all as it was important for security reasons.

Reports of what having bad performance?

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

On 22 Apr 2013, at 08:19, Dan Berindei  wrote:

> 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.
> 
> 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?

Possibly.  

> 
> 
> 
> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd  
> wrote:
> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
> > On 19 April 2013 13:52, David M. Lloyd  wrote:
> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> >>> On 19 April 2013 11:10, Dan Berindei  wrote:
> 
> 
> 
>  On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero 
>  wrote:
> >
> > On 19 April 2013 10:37, Dan Berindei  wrote:
> >> Testing mixed read/write performance with capacity 10, keys 30,
> >> 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..
> 
> You are right, it is not superior on all fronts.  It is definitely
> similar in terms of read, but writes will have a substantially higher
> cost, involving (at the very least) multiple volatile writes which are
> orders of magnitude more expensive than normal writes (on Intel they
> have the costly impact of memory fence instructions).  So I don't think
> anyone will want to drop HashMap any time soon. :-)
> 
> --
> - DML
> 

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

We also have been toying with the idea to hash each key only once,
instead of both with the consistent hash (to assign the node owner)
and once in the CHM backing the datacontainer.
I doubt we need the datacontainer to implement Map at all, but at
least if we go this way we don't want the hash to be affected by the
VM instance or different nodes won't agree on the expected owner ;-)

Also there where reports of it having a very bad impact on
performance, I'm not sure if they where resolved yet, or are going to
be resolved at all as it was important for security reasons.


On 22 April 2013 12:19, Dan Berindei  wrote:
> 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.
>
> 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?
>
>
>
> On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd 
> wrote:
>>
>> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
>> > On 19 April 2013 13:52, David M. Lloyd  wrote:
>> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> >>> On 19 April 2013 11:10, Dan Berindei  wrote:
>> 
>> 
>> 
>>  On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero
>>  
>>  wrote:
>> >
>> > On 19 April 2013 10:37, Dan Berindei  wrote:
>> >> Testing mixed read/write performance with capacity 10, keys
>> >> 30,
>> >> 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 w

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

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.

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?



On Fri, Apr 19, 2013 at 4:32 PM, David M. Lloyd wrote:

> On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
> > On 19 April 2013 13:52, David M. Lloyd  wrote:
> >> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> >>> On 19 April 2013 11:10, Dan Berindei  wrote:
> 
> 
> 
>  On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero <
> sa...@infinispan.org>
>  wrote:
> >
> > On 19 April 2013 10:37, Dan Berindei  wrote:
> >> Testing mixed read/write performance with capacity 10, keys
> 30,
> >> 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..
>
> You are right, it is not superior on all fronts.  It is definitely
> similar in terms of read, but writes will have a substantially higher
> cost, involving (at the very least) multiple volatile writes which are
> orders of magnitude more expensive than normal writes (on Intel they
> have the costly impact of memory fence instructions).  So I don't think
> anyone will want to drop HashMap any time soon. :-)
>
> --
> - DML
> ___
> infinispan-dev mailing list
> i

Re: [infinispan-dev] CHM or CHMv8?

[David M. Lloyd]

On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
> On 19 April 2013 13:52, David M. Lloyd  wrote:
>> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>>> On 19 April 2013 11:10, Dan Berindei  wrote:



 On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero 
 wrote:
>
> On 19 April 2013 10:37, Dan Berindei  wrote:
>> Testing mixed read/write performance with capacity 10, keys 30,
>> 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..

You are right, it is not superior on all fronts.  It is definitely 
similar in terms of read, but writes will have a substantially higher 
cost, involving (at the very least) multiple volatile writes which are 
orders of magnitude more expensive than normal writes (on Intel they 
have the costly impact of memory fence instructions).  So I don't think 
anyone will want to drop HashMap any time soon. :-)

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

On 19 April 2013 13:52, David M. Lloyd  wrote:
> On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
>> On 19 April 2013 11:10, Dan Berindei  wrote:
>>>
>>>
>>>
>>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero 
>>> wrote:

 On 19 April 2013 10:37, Dan Berindei  wrote:
> Testing mixed read/write performance with capacity 10, keys 30,
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[David M. Lloyd]

On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
> On 19 April 2013 11:10, Dan Berindei  wrote:
>>
>>
>>
>> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero 
>> wrote:
>>>
>>> On 19 April 2013 10:37, Dan Berindei  wrote:
 Testing mixed read/write performance with capacity 10, keys 30,
 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

Re: [infinispan-dev] CHM or CHMv8?

[Mircea Markus]

On 19 Apr 2013, at 13:16, Manik Surtani wrote:

> https://issues.jboss.org/browse/ISPN-3022
> 
> In fact, we should also re-implement the BoundedConcurrentHashMap - the basis 
> for LIRS and LRU eviction algorithms - to use techniques similar to CHMv8 
> rather than the old segment-based approach.  
> 
> https://issues.jboss.org/browse/ISPN-3023
> 
> Anyone has a few spare cycles - and is really good with complex concurrency 
> code - want to take this on?  ;)

Whilst this is nice to have, I don't think this should be tackled now, unless 
some contributor is willing to look at it.
We have quite some bugs that need fixing first, then performance :)

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)





___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Mircea Markus]

On 19 Apr 2013, at 08:47, Dan Berindei wrote:

> +1 to make CHMv8 the default on JDK6 and JDK7
+1

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)




___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

Ok, I've created 

https://issues.jboss.org/browse/ISPN-3022

In fact, we should also re-implement the BoundedConcurrentHashMap - the basis 
for LIRS and LRU eviction algorithms - to use techniques similar to CHMv8 
rather than the old segment-based approach.  

https://issues.jboss.org/browse/ISPN-3023

Anyone has a few spare cycles - and is really good with complex concurrency 
code - want to take this on?  ;)

- M

On 19 Apr 2013, at 09:06, Manik Surtani  wrote:

> 
> On 19 Apr 2013, at 05:07, Sanne Grinovero  wrote:
> 
>> Why not. Only doubt I'd have is that other usages of the CHM are - I guess - 
>> services registry and similar configuration tools, for which write 
>> performance is irrelevant: your test measured puts, are there drawbacks on 
>> gets or memory usage?
>> 
> See the original announcement on concurrency-interest by Doug Lea, and the 
> subsequent comments.  The design is up here too.  One of the goals was to 
> drastically reduce memory usage with CHMv8.
> 
> http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/8140
> 
> Interestingly, Netty uses a backported CHMv8 as well - apparently inspired by 
> our inclusion of it in Infinispan.  ;)
> 
> https://github.com/netty/netty/issues/1052
> 
> -M
> 
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
> 
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
> 

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

On 19 Apr 2013, at 05:07, Sanne Grinovero  wrote:

> Why not. Only doubt I'd have is that other usages of the CHM are - I guess - 
> services registry and similar configuration tools, for which write 
> performance is irrelevant: your test measured puts, are there drawbacks on 
> gets or memory usage?
> 
See the original announcement on concurrency-interest by Doug Lea, and the 
subsequent comments.  The design is up here too.  One of the goals was to 
drastically reduce memory usage with CHMv8.

http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/8140

Interestingly, Netty uses a backported CHMv8 as well - apparently inspired by 
our inclusion of it in Infinispan.  ;)

https://github.com/netty/netty/issues/1052

-M

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Manik Surtani]

Whoops, my mistake, this *was* on JDK 7.

On 19 Apr 2013, at 04:11, Radim Vansa  wrote:

> Do you have the numbers for JDK 7 as well?
> 
> Radim
> 
> - Original Message -
> | From: "Manik Surtani" 
> | To: "infinispan -Dev List" 
> | Sent: Friday, April 19, 2013 4:35:53 AM
> | Subject: [infinispan-dev] CHM or CHMv8?
> | 
> | Guys,
> | 
> | Based on some recent micro benchmarks I've been doing, I've seen:
> | 
> | MapStressTest configuration: capacity 10, test running time 60 seconds
> | Testing mixed read/write performance with capacity 100,000, keys 300,000,
> | concurrency level 32, threads 12, read:write ratio 0:1
> | Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
> | 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
> | Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
> | 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
> | 
> | So under high concurrency (12 threads, on my workstation with 12 hardware
> | threads - so all threads are always working), we see that Infinispan's CHMv8
> | implementation is 50% faster than JDK6's CHM implementation when doing puts.
> | 
> | We use a fair number of CHMs all over Infinispan's codebase.  By default,
> | these are all JDK-provided CHMs.  But we have the option to switch to our
> | CHMv8 implementation by passing in -Dinfinispan.unsafe.allow_jdk8_chm=true.
> | 
> | The question is, should this be the default?  Thoughts, opinions?
> | 
> | - M
> | 
> | --
> | Manik Surtani
> | ma...@jboss.org
> | twitter.com/maniksurtani
> | 
> | Platform Architect, JBoss Data Grid
> | http://red.ht/data-grid
> | 
> | 
> | ___
> | infinispan-dev mailing list
> | infinispan-dev@lists.jboss.org
> | https://lists.jboss.org/mailman/listinfo/infinispan-dev
> | 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

On 19 April 2013 11:10, Dan Berindei  wrote:
>
>
>
> On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero 
> wrote:
>>
>> On 19 April 2013 10:37, Dan Berindei  wrote:
>> > Testing mixed read/write performance with capacity 10, keys 30,
>> > 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!)

Cheers,
Sanne
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero wrote:

> On 19 April 2013 10:37, Dan Berindei  wrote:
> > Testing mixed read/write performance with capacity 10, keys 30,
> > 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 :)

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.


> >
> >
> >
> >
> > On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero 
> > wrote:
> >>
> >> Why not. Only doubt I'd have is that other usages of the CHM are - I
> guess
> >> - services registry and similar configuration tools, for which write
> >> performance is irrelevant: your test measured puts, are there drawbacks
> on
> >> gets or memory usage?
> >>
> >> Recently you changed all (most?) CHM creations to use a consistent
> >> factory, maybe we could improve on that by actually using a couple of
> >> factories which differentiate on the intended usage of the CHM: for
> example
> >> some maps who change very infrequently - mostly during boot or
> >> reconfiguration, maybe even topology change - could be better served by
> a
> >> non concurrent structure using copy-on-wrtite.
> >>
> >> Sanne
> >>
> >> On 19 Apr 2013 08:48, "Dan Berindei"  wrote:
> >>>
> >>> +1 to make CHMv8 the default on JDK6 and JDK7
> >>>
> >>> But I'm not convinced we should make it the default for JDK8 - even
> >>> though we don't know exactly what we're getting with the JDK's
> >>> implementation.
> >>>
> >>>
> >>> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd <
> david.ll...@redhat.com>
> >>> wrote:
> 
>  On 04/18/2013 09:35 PM, Manik Surtani wrote:
>  > Guys,
>  >
>  > Based on some recent micro benchmarks I've been doing, I've seen:
>  >
>  > MapStressTest configuration: capacity 10, test running time 60
>  > seconds
>  > Testing mixed read/write performance with capacity 100,000, keys
>  > 300,000, concurrency level 32, threads 12, read:write ratio 0:1
>  > Container CHM   Ops/s 21,165,771.67  Gets/s   0.00
>  Puts/s
>  > 21,165,771.67  HitRatio 100.00  Size262,682  stdDev
> 77,540.73
>  > Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00
>  Puts/s
>  > 33,513,807.09  HitRatio 100.00  Size262,682  stdDev
> 77,540.73
>  >
>  > So under high concurrency (12 threads, on my workstation with 12
>  > hardware threads - so all threads are always working), we see that
>  > Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
>  > implementation when doing puts.
>  >
>  > We use a fair number of CHMs all over Infinispan's codebase.  By
>  > default, these are all JDK-provided CHMs.  But we have the option
> to switch
>  > to our CHMv8 implementation by passing in
>  > -Dinfinispan.unsafe.allow_jdk8_chm=true.
>  >
>  > The question is, should this be the default?  Thoughts, opinions?
> 
>  The JDK's concurrency code - especially CHM - changes all the time.
>  You'd be very well-served, in my opinion, to go with something like
>  CHMv8 just because you could be so much more sure that you'll have
> more
>  consistent (and possibly better, but definitely more consistent)
>  performance across all JVMs, instead of being at the mercy of whatever
>  particular implementation happens to run on whatever JVM.
> 
> 
>  --
>  - DML
>  ___
>  infinispan-

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

On 19 April 2013 10:37, Dan Berindei  wrote:
> Testing mixed read/write performance with capacity 10, keys 30,
> 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?

Sanne


>
>
>
>
> On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero 
> wrote:
>>
>> Why not. Only doubt I'd have is that other usages of the CHM are - I guess
>> - services registry and similar configuration tools, for which write
>> performance is irrelevant: your test measured puts, are there drawbacks on
>> gets or memory usage?
>>
>> Recently you changed all (most?) CHM creations to use a consistent
>> factory, maybe we could improve on that by actually using a couple of
>> factories which differentiate on the intended usage of the CHM: for example
>> some maps who change very infrequently - mostly during boot or
>> reconfiguration, maybe even topology change - could be better served by a
>> non concurrent structure using copy-on-wrtite.
>>
>> Sanne
>>
>> On 19 Apr 2013 08:48, "Dan Berindei"  wrote:
>>>
>>> +1 to make CHMv8 the default on JDK6 and JDK7
>>>
>>> But I'm not convinced we should make it the default for JDK8 - even
>>> though we don't know exactly what we're getting with the JDK's
>>> implementation.
>>>
>>>
>>> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd 
>>> wrote:

 On 04/18/2013 09:35 PM, Manik Surtani wrote:
 > Guys,
 >
 > Based on some recent micro benchmarks I've been doing, I've seen:
 >
 > MapStressTest configuration: capacity 10, test running time 60
 > seconds
 > Testing mixed read/write performance with capacity 100,000, keys
 > 300,000, concurrency level 32, threads 12, read:write ratio 0:1
 > Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
 > 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
 > Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
 > 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
 >
 > So under high concurrency (12 threads, on my workstation with 12
 > hardware threads - so all threads are always working), we see that
 > Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
 > implementation when doing puts.
 >
 > We use a fair number of CHMs all over Infinispan's codebase.  By
 > default, these are all JDK-provided CHMs.  But we have the option to 
 > switch
 > to our CHMv8 implementation by passing in
 > -Dinfinispan.unsafe.allow_jdk8_chm=true.
 >
 > The question is, should this be the default?  Thoughts, opinions?

 The JDK's concurrency code - especially CHM - changes all the time.
 You'd be very well-served, in my opinion, to go with something like
 CHMv8 just because you could be so much more sure that you'll have more
 consistent (and possibly better, but definitely more consistent)
 performance across all JVMs, instead of being at the mercy of whatever
 particular implementation happens to run on whatever JVM.


 --
 - DML
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@l

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

Testing mixed read/write performance with capacity 10, keys 30,
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

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.




On Fri, Apr 19, 2013 at 11:07 AM, Sanne Grinovero wrote:

> Why not. Only doubt I'd have is that other usages of the CHM are - I guess
> - services registry and similar configuration tools, for which write
> performance is irrelevant: your test measured puts, are there drawbacks on
> gets or memory usage?
>
> Recently you changed all (most?) CHM creations to use a consistent
> factory, maybe we could improve on that by actually using a couple of
> factories which differentiate on the intended usage of the CHM: for example
> some maps who change very infrequently - mostly during boot or
> reconfiguration, maybe even topology change - could be better served by a
> non concurrent structure using copy-on-wrtite.
>
> Sanne
> On 19 Apr 2013 08:48, "Dan Berindei"  wrote:
>
>> +1 to make CHMv8 the default on JDK6 and JDK7
>>
>> But I'm not convinced we should make it the default for JDK8 - even
>> though we don't know exactly what we're getting with the JDK's
>> implementation.
>>
>>
>> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd 
>> wrote:
>>
>>> On 04/18/2013 09:35 PM, Manik Surtani wrote:
>>> > Guys,
>>> >
>>> > Based on some recent micro benchmarks I've been doing, I've seen:
>>> >
>>> > MapStressTest configuration: capacity 10, test running time 60
>>> seconds
>>> > Testing mixed read/write performance with capacity 100,000, keys
>>> 300,000, concurrency level 32, threads 12, read:write ratio 0:1
>>> > Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
>>> 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
>>> > Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
>>> 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
>>> >
>>> > So under high concurrency (12 threads, on my workstation with 12
>>> hardware threads - so all threads are always working), we see that
>>> Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
>>> implementation when doing puts.
>>> >
>>> > We use a fair number of CHMs all over Infinispan's codebase.  By
>>> default, these are all JDK-provided CHMs.  But we have the option to switch
>>> to our CHMv8 implementation by passing in
>>> -Dinfinispan.unsafe.allow_jdk8_chm=true.
>>> >
>>> > The question is, should this be the default?  Thoughts, opinions?
>>>
>>> The JDK's concurrency code - especially CHM - changes all the time.
>>> You'd be very well-served, in my opinion, to go with something like
>>> CHMv8 just because you could be so much more sure that you'll have more
>>> consistent (and possibly better, but definitely more consistent)
>>> performance across all JVMs, instead of being at the mercy of whatever
>>> particular implementation happens to run on whatever JVM.
>>>
>>>
>>> --
>>> - DML
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Sanne Grinovero]

Why not. Only doubt I'd have is that other usages of the CHM are - I guess
- services registry and similar configuration tools, for which write
performance is irrelevant: your test measured puts, are there drawbacks on
gets or memory usage?

Recently you changed all (most?) CHM creations to use a consistent factory,
maybe we could improve on that by actually using a couple of factories
which differentiate on the intended usage of the CHM: for example some maps
who change very infrequently - mostly during boot or reconfiguration, maybe
even topology change - could be better served by a non concurrent structure
using copy-on-wrtite.

Sanne
On 19 Apr 2013 08:48, "Dan Berindei"  wrote:

> +1 to make CHMv8 the default on JDK6 and JDK7
>
> But I'm not convinced we should make it the default for JDK8 - even though
> we don't know exactly what we're getting with the JDK's implementation.
>
>
> On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd wrote:
>
>> On 04/18/2013 09:35 PM, Manik Surtani wrote:
>> > Guys,
>> >
>> > Based on some recent micro benchmarks I've been doing, I've seen:
>> >
>> > MapStressTest configuration: capacity 10, test running time 60
>> seconds
>> > Testing mixed read/write performance with capacity 100,000, keys
>> 300,000, concurrency level 32, threads 12, read:write ratio 0:1
>> > Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
>> 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
>> > Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
>> 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
>> >
>> > So under high concurrency (12 threads, on my workstation with 12
>> hardware threads - so all threads are always working), we see that
>> Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
>> implementation when doing puts.
>> >
>> > We use a fair number of CHMs all over Infinispan's codebase.  By
>> default, these are all JDK-provided CHMs.  But we have the option to switch
>> to our CHMv8 implementation by passing in
>> -Dinfinispan.unsafe.allow_jdk8_chm=true.
>> >
>> > The question is, should this be the default?  Thoughts, opinions?
>>
>> The JDK's concurrency code - especially CHM - changes all the time.
>> You'd be very well-served, in my opinion, to go with something like
>> CHMv8 just because you could be so much more sure that you'll have more
>> consistent (and possibly better, but definitely more consistent)
>> performance across all JVMs, instead of being at the mercy of whatever
>> particular implementation happens to run on whatever JVM.
>>
>>
>> --
>> - DML
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Dan Berindei]

+1 to make CHMv8 the default on JDK6 and JDK7

But I'm not convinced we should make it the default for JDK8 - even though
we don't know exactly what we're getting with the JDK's implementation.


On Fri, Apr 19, 2013 at 5:39 AM, David M. Lloyd wrote:

> On 04/18/2013 09:35 PM, Manik Surtani wrote:
> > Guys,
> >
> > Based on some recent micro benchmarks I've been doing, I've seen:
> >
> > MapStressTest configuration: capacity 10, test running time 60
> seconds
> > Testing mixed read/write performance with capacity 100,000, keys
> 300,000, concurrency level 32, threads 12, read:write ratio 0:1
> > Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
> 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
> > Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
> 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
> >
> > So under high concurrency (12 threads, on my workstation with 12
> hardware threads - so all threads are always working), we see that
> Infinispan's CHMv8 implementation is 50% faster than JDK6's CHM
> implementation when doing puts.
> >
> > We use a fair number of CHMs all over Infinispan's codebase.  By
> default, these are all JDK-provided CHMs.  But we have the option to switch
> to our CHMv8 implementation by passing in
> -Dinfinispan.unsafe.allow_jdk8_chm=true.
> >
> > The question is, should this be the default?  Thoughts, opinions?
>
> The JDK's concurrency code - especially CHM - changes all the time.
> You'd be very well-served, in my opinion, to go with something like
> CHMv8 just because you could be so much more sure that you'll have more
> consistent (and possibly better, but definitely more consistent)
> performance across all JVMs, instead of being at the mercy of whatever
> particular implementation happens to run on whatever JVM.
>
>
> --
> - DML
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[Radim Vansa]

Do you have the numbers for JDK 7 as well?

Radim

- Original Message -
| From: "Manik Surtani" 
| To: "infinispan -Dev List" 
| Sent: Friday, April 19, 2013 4:35:53 AM
| Subject: [infinispan-dev] CHM or CHMv8?
| 
| Guys,
| 
| Based on some recent micro benchmarks I've been doing, I've seen:
| 
| MapStressTest configuration: capacity 10, test running time 60 seconds
| Testing mixed read/write performance with capacity 100,000, keys 300,000,
| concurrency level 32, threads 12, read:write ratio 0:1
| Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s
| 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
| Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s
| 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
| 
| So under high concurrency (12 threads, on my workstation with 12 hardware
| threads - so all threads are always working), we see that Infinispan's CHMv8
| implementation is 50% faster than JDK6's CHM implementation when doing puts.
| 
| We use a fair number of CHMs all over Infinispan's codebase.  By default,
| these are all JDK-provided CHMs.  But we have the option to switch to our
| CHMv8 implementation by passing in -Dinfinispan.unsafe.allow_jdk8_chm=true.
| 
| The question is, should this be the default?  Thoughts, opinions?
| 
| - M
| 
| --
| Manik Surtani
| ma...@jboss.org
| twitter.com/maniksurtani
| 
| Platform Architect, JBoss Data Grid
| http://red.ht/data-grid
| 
| 
| ___
| infinispan-dev mailing list
| infinispan-dev@lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/infinispan-dev
| 
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

[David M. Lloyd]

On 04/18/2013 09:35 PM, Manik Surtani wrote:
> Guys,
>
> Based on some recent micro benchmarks I've been doing, I've seen:
>
> MapStressTest configuration: capacity 10, test running time 60 seconds
> Testing mixed read/write performance with capacity 100,000, keys 300,000, 
> concurrency level 32, threads 12, read:write ratio 0:1
> Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s 
> 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
> Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s 
> 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73
>
> So under high concurrency (12 threads, on my workstation with 12 hardware 
> threads - so all threads are always working), we see that Infinispan's CHMv8 
> implementation is 50% faster than JDK6's CHM implementation when doing puts.
>
> We use a fair number of CHMs all over Infinispan's codebase.  By default, 
> these are all JDK-provided CHMs.  But we have the option to switch to our 
> CHMv8 implementation by passing in -Dinfinispan.unsafe.allow_jdk8_chm=true.
>
> The question is, should this be the default?  Thoughts, opinions?

The JDK's concurrency code - especially CHM - changes all the time. 
You'd be very well-served, in my opinion, to go with something like 
CHMv8 just because you could be so much more sure that you'll have more 
consistent (and possibly better, but definitely more consistent) 
performance across all JVMs, instead of being at the mercy of whatever 
particular implementation happens to run on whatever JVM.


-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev