<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 30 Jan 2013, at 09:14, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></div></blockquote><div><br></div><div>I suspect so as well, TBH.</div><br><blockquote type="cite"><div dir="ltr">
<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>
_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div><div>Platform Architect, JBoss Data Grid</div><div><a href="http://red.ht/data-grid">http://red.ht/data-grid</a></div></div></div></span></div></span></div></span>
</div>
<br></body></html>