<div dir="ltr"><div><div>Manik, I think that JDK bug is pretty out-of-date, at least on Fedora.<br><br></div>I ran the micro-benchmark in the bug (with some modifications: <a href="https://github.com/danberindei/infinispan/blob/t_time_sources_test/core/src/test/java/org/infinispan/TimeSourcesTest.java">https://github.com/danberindei/infinispan/blob/t_time_sources_test/core/src/test/java/org/infinispan/TimeSourcesTest.java</a>) when we had the last round of discussions on this:<br>
<br>nanoTime: 4209836189827226918, time/call: 24ns<br>currentTimeMillis: 4209836189827226918, time/call: 31ns<br><br></div>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.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 10:53 AM, Manik Surtani <span dir="ltr"><<a href="mailto:msurtani@redhat.com" target="_blank">msurtani@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 30 Jan 2013, at 08:41, Bela Ban <<a href="mailto:bban@redhat.com">bban@redhat.com</a>> wrote:<br>
<br>
><br>
> On 1/29/13 6:45 PM, Manik Surtani wrote:<br>
>> On 29 Jan 2013, at 17:17, Bela Ban <<a href="mailto:bban@redhat.com">bban@redhat.com</a>> wrote:<br>
>><br>
>>> On 1/29/13 5:25 PM, Sanne Grinovero wrote:<br>
>>>> Glad you started work on that :)<br>
>>>><br>
>>>> Any currentTimeMillis() even today will blow away your cache line and<br>
>>>> probably trigger a context switch.<br>
>>> I understand the context switch (in general, it's not recommended anyway<br>
>>> to invoke a system call in synchronized code), but I fail to see why<br>
>>> this would blow the cache line. Are you referring to the cached Date<br>
>>> value here ?<br>
>> No, if you have a separate maint thread that updates a reusable currentTimeMillis value.<br>
>><br>
>> Do you use nanoTime() a lot then? Because that too is inefficient (as per the Oracle blog) ...<br>
><br>
> Define inefficient !<br>
<br>
</div>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.<br>
<br>
<a href="http://bugs.sun.com/view_bug.do?bug_id=6876279" target="_blank">http://bugs.sun.com/view_bug.do?bug_id=6876279</a><br>
<div class="im"><br>
> I'm sure we're talking about nanosec / microsec<br>
> ranges here, so 3% faster won't cut it for me. If you contrast that to<br>
> my current work, where I try to deliver a batch of N messages and<br>
> therefore can skip N-1 lock acquitions/releases for M protocols, then<br>
</div>> the latter wins…<br>
<br>
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.<br>
<div class="im"><br>
> I still think a clock service is interesting, but for different reasons.<br>
> As Sanne mentioned in Palma, it would be interesting to 'control' time,<br>
> e.g. deliver 2 messages at the same time, or even go backwards in time.<br>
> In the case of JGroups, we could use a clock service to screw up message<br>
> reception (e.g. in testing) and therefore to test the correctness of<br>
> some protocols.<br>
<br>
</div>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
- M<br>
</font></span><div class="im HOEnZb"><br>
><br>
> --<br>
> Bela Ban, JGroups lead (<a href="http://www.jgroups.org" target="_blank">http://www.jgroups.org</a>)<br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
</div><div class="im HOEnZb">--<br>
Manik Surtani<br>
<a href="mailto:manik@jboss.org">manik@jboss.org</a><br>
<a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a><br>
<br>
Platform Architect, JBoss Data Grid<br>
<a href="http://red.ht/data-grid" target="_blank">http://red.ht/data-grid</a><br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>