Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this: https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very The last section re: caching is interesting. Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns: * CPU cache line blowing away (see article) * Context switching * Managing an extra service thread * Probably an additional configuration option to configure that thread, its priority and frequency. If frequency is dropped (e.g., every second) I suppose the perf gains would be huge. JGroups - does JGroups make many and frequent calls to System.cTM as well? Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Interesting; looking at the code a bit more, I don't think this offers any improvements except in the case where expiry is set. Granted, this is a useful thing to have at that point, but I'm not entirely sure whether it will affect the majority of users.

Anyway, to measure any benefit, I'm also going to have to enhance RadarGun to (optionally) set expiry information on data stored. - M On 29 Jan 2013, at 16:25, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > Glad you started work on that :) > > Any currentTimeMillis() even today will blow away your cache line and > probably trigger a context switch. > > Having it as a service we will be able to experiment: the first thing > I'll do is replace it with a NOOPService and see how much it improves. > > Ideally I'd like it to have multiple methods so that different needs > can hint about a different level of precision, or maybe expect an enum > as parameter which represents the hint. > > Cheers, > Sanne > > On 29 January 2013 16:02, Manik Surtani <msurtani(a)redhat.com&gt; wrote: >> Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this: >> >> https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very >> >> The last section re: caching is interesting. >> >> Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns: >> >> * CPU cache line blowing away (see article) >> * Context switching >> * Managing an extra service thread >> * Probably an additional configuration option to configure that thread, its priority and frequency. If frequency is dropped (e.g., every second) I suppose the perf gains would be huge. >> >> JGroups - does JGroups make many and frequent calls to System.cTM as well? >> >> Cheers >> Manik >> -- >> Manik Surtani >> manik(a)jboss.org >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 1/29/13 5:25 PM, Sanne Grinovero wrote: > Glad you started work on that :) > > Any currentTimeMillis() even today will blow away your cache line and > probably trigger a context switch. I understand the context switch (in general, it's not recommended anyway to invoke a system call in synchronized code), but I fail to see why this would blow the cache line. Are you referring to the cached Date value here ?

I guess Bela's question was about why System. currentTimeMillis() would trigger a context switch, I'm also curious about that one :-)

On 29 Jan 2013, at 17:17, Bela Ban <bban(a)redhat.com&gt; wrote: > On 1/29/13 5:25 PM, Sanne Grinovero wrote: >> Glad you started work on that :) >> >> Any currentTimeMillis() even today will blow away your cache line and >> probably trigger a context switch. > I understand the context switch (in general, it's not recommended anyway > to invoke a system call in synchronized code), but I fail to see why > this would blow the cache line. Are you referring to the cached Date > value here ? No, if you have a separate maint thread that updates a reusable currentTimeMillis value. Do you use nanoTime() a lot then? Because that too is inefficient (as per the Oracle blog) ...

> Define inefficient ! There was once a misconception that nanoTime() was faster (by an order of magnitude) that currentTimeMillis(). And a similar misconception going the other way. The reality, it would seem, is that they're both *fairly inefficient*, depending on OS architecture. http://bugs.sun.com/view_bug.do?bug_id=6876279 > I'm sure we're talking about nanosec / microsec > ranges here, so 3% faster won't cut it for me. If you contrast that to > my current work, where I try to deliver a batch of N messages and > therefore can skip N-1 lock acquitions/releases for M protocols, then > the latter wins… Right, I'm not entirely sure it is a hotspot for optimisation though. I'm going by some research that Sanne did and I'm doing a bit more homework around that. > I still think a clock service is interesting, but for different reasons. > As Sanne mentioned in Palma, it would be interesting to 'control' time, > e.g. deliver 2 messages at the same time, or even go backwards in time. > In the case of JGroups, we could use a clock service to screw up message > reception (e.g. in testing) and therefore to test the correctness of > some protocols. Right, but for me that would be an additional benefit and I would de-prioritise if that was all I was getting from it. If it is even a moderate performance boost though, say over 3% overall for such a small/simple change, then I'd do it.

Manik, I think that JDK bug is pretty out-of-date, at least on Fedora. I ran the micro-benchmark in the bug (with some modifications: https://github.com/danberindei/infinispan/blob/t_time_sources_test/core/s...) when we had the last round of discussions on this: nanoTime: 4209836189827226918, time/call: 24ns currentTimeMillis: 4209836189827226918, time/call: 31ns The bug initially reported 7ns/call with an optimization that cached the last currentTimeMillis() value, so I'm not sure how much better we could get with our own ClockService implementation. I'm pretty sure a 3% overall improvement is out of reach, though.

On Wed, Jan 30, 2013 at 10:53 AM, Manik Surtani <msurtani(a)redhat.com&gt; wrote: On 30 Jan 2013, at 08:41, Bela Ban <bban(a)redhat.com&gt; wrote: > > On 1/29/13 6:45 PM, Manik Surtani wrote: >> On 29 Jan 2013, at 17:17, Bela Ban <bban(a)redhat.com&gt; wrote: >> >>> On 1/29/13 5:25 PM, Sanne Grinovero wrote: >>>> Glad you started work on that :) >>>> >>>> Any currentTimeMillis() even today will blow away your cache line and >>>> probably trigger a context switch. >>> I understand the context switch (in general, it's not recommended anyway >>> to invoke a system call in synchronized code), but I fail to see why >>> this would blow the cache line. Are you referring to the cached Date >>> value here ? >> No, if you have a separate maint thread that updates a reusable currentTimeMillis value. >> >> Do you use nanoTime() a lot then? Because that too is inefficient (as per the Oracle blog) ... > > Define inefficient ! There was once a misconception that nanoTime() was faster (by an order of magnitude) that currentTimeMillis(). And a similar misconception going the other way. The reality, it would seem, is that they're both *fairly inefficient*, depending on OS architecture. http://bugs.sun.com/view_bug.do?bug_id=6876279 > I'm sure we're talking about nanosec / microsec > ranges here, so 3% faster won't cut it for me. If you contrast that to > my current work, where I try to deliver a batch of N messages and > therefore can skip N-1 lock acquitions/releases for M protocols, then > the latter wins… Right, I'm not entirely sure it is a hotspot for optimisation though. I'm going by some research that Sanne did and I'm doing a bit more homework around that. > I still think a clock service is interesting, but for different reasons. > As Sanne mentioned in Palma, it would be interesting to 'control' time, > e.g. deliver 2 messages at the same time, or even go backwards in time. > In the case of JGroups, we could use a clock service to screw up message > reception (e.g. in testing) and therefore to test the correctness of > some protocols. Right, but for me that would be an additional benefit and I would de-prioritise if that was all I was getting from it. If it is even a moderate performance boost though, say over 3% overall for such a small/simple change, then I'd do it. - M > > -- > Bela Ban, JGroups lead (http://www.jgroups.org) > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Glad you started work on that :) Any currentTimeMillis() even today will blow away your cache line and probably trigger a context switch. Having it as a service we will be able to experiment: the first thing I'll do is replace it with a NOOPService and see how much it improves.

Ideally I'd like it to have multiple methods so that different needs can hint about a different level of precision, or maybe expect an enum as parameter which represents the hint. Cheers, Sanne On 29 January 2013 16:02, Manik Surtani <msurtani(a)redhat.com&gt; wrote: > Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this: > > https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very > > The last section re: caching is interesting. > > Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns: > > * CPU cache line blowing away (see article) > * Context switching > * Managing an extra service thread > * Probably an additional configuration option to configure that thread, its priority and frequency. If frequency is dropped (e.g., every second) I suppose the perf gains would be huge. > > JGroups - does JGroups make many and frequent calls to System.cTM as well? > > Cheers > Manik > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this: https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very The last section re: caching is interesting. Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns: * CPU cache line blowing away (see article) * Context switching * Managing an extra service thread * Probably an additional configuration option to configure that thread, its priority and frequency. If frequency is dropped (e.g., every second) I suppose the perf gains would be huge. JGroups - does JGroups make many and frequent calls to System.cTM as well?