Re: [infinispan-dev] Time measurement and expiry
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(a)gmail.com> wrote:
On Tue, Oct 18, 2011 at 1:32 AM, Mircea Markus
<mircea.markus(a)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/Realtim...
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtim...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev