On 30 Jan 2013, at 09:14, Dan Berindei <dan.berin...@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 <msurt...@redhat.com> wrote: > > On 30 Jan 2013, at 08:41, Bela Ban <b...@redhat.com> wrote: > > > > > On 1/29/13 6:45 PM, Manik Surtani wrote: > >> On 29 Jan 2013, at 17:17, Bela Ban <b...@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@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 > > _______________________________________________ > 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
