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