[infinispan-dev] Time measurement and expiry

[Sanne Grinovero]

The replies so far are very interesting, but at this stage I'd be more
interested in discussing the fundamental question:

Why are we preferring to provide more cache misses && slower
performance, to fake a slightly better precision in eviction?

Since we can't guarantee precision, I'd want to actually remove these
checks altogether: is there any use case requiring high precision in
the eviction process?
I hope not, I wouldn't suggest to rely on Infinispan as a reliable clock.

In the couple of cases we should really keep this logic - likely the
CacheLoader - we can discuss how to optimize this. For example I like
Dan's idea of introducing a Clock component; we could explore such
solutions for the remaining bits which will still need a time source
but I'd first want to remove the main bottleneck.

--Sanne


On 18 October 2011 07:57, Dan Berindei <dan.berindei at gmail.com> 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
>