[infinispan-dev] ClockService

[Manik Surtani]

On 30 Jan 2013, at 09:14, Dan Berindei <dan.berindei at gmail.com> wrote:

> 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/src/test/java/org/infinispan/TimeSourcesTest.java) 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.

I suspect so as well, TBH.

> 
> 
> 
> On Wed, Jan 30, 2013 at 10:53 AM, Manik Surtani <msurtani at redhat.com> wrote:
> 
> On 30 Jan 2013, at 08:41, Bela Ban <bban at redhat.com> wrote:
> 
> >
> > On 1/29/13 6:45 PM, Manik Surtani wrote:
> >> On 29 Jan 2013, at 17:17, Bela Ban <bban at redhat.com> 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130130/bb0eac43/attachment-0001.html