[infinispan-dev] Time measurement and expiry

[Mircea Markus]

Thanks for the clarification Dan!
On 18 Oct 2011, at 07:57, Dan Berindei wrote:

> On Tue, Oct 18, 2011 at 1:32 AM, Mircea Markus <mircea.markus at jboss.com> wrote:
>> 
>> On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
>> 
>>>> Very interesting, I knew that in Windows currentTimeMillis() basically
>>>> just reads a volatile because I got bit by the 15 millisecond accuracy
>>>> issue before, so I thought it would always be very fast. I had no idea
>>>> on Linux it would have the same performance as nanoTime().
>> Indeed very nice!
>> I miss the part where the article says nanoTime has the same performance on modern Linux as currentTimeMillis, are you sure?
> 
> Yeah, the article didn't talk about Linux but I found this article:
> http://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
> There's also this JDK bug complaining about both being slow:
> http://bugs.sun.com/view_bug.do?bug_id=6876279  (the test output is in
> a weird format, ignore the 1st number, the 2nd one is nanos/call).
> Except when I actually ran the code in the bug report I my timings
> were much better than those reported in the bug description:
> 
> java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-x86_64)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> Intel(R) Core(TM) i5 CPU       M 540  @ 2.53GHz
> 
> currentTimeMillis: 36ns
> nanoTime: 28ns
> 
> -server or -XX:AggressiveOpts don't seem to make a difference.
> 
> 
> I also ran the test on cluster10 and the results are slightly worse,
> but not significantly:
> 
> java version "1.6.0_17"
> OpenJDK Runtime Environment (IcedTea6 1.7.10) (rhel-1.39.b17.el6_0-x86_64)
> OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
> Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz
> 
> currentTimeMillis: 40ns
> nanoTime: 35ns
> 
> 
> It would be interesting if we could run the test on all our machines
> and see how the timings vary by machine and OS.
> 
> 
> It seems we're not the only ones with this problem either, Oracle (the
> database) apparently calls gettimeofday() a lot so RHEL has some
> optimizations to remove the system call overhead and make it even
> faster (more like Windows I presume, but I don't have a Windows
> machine on hand to confirm):
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-RT_Specific_gettimeofday_speedup.html
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev