Hi Aleksey,

The test I used is simple:

https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java

I ran it on a i7-2600K (4 cores x 2 threads) PC with Linux OS and a JDK8 build from lambda repo using default JVM options (that means +UseCompressedOops enabled by default).

Can you give the sources of your tests so I could try to run them on my machine?

Regards, Peter

On 01/16/2013 10:13 AM, Aleksey Shipilev wrote:
Hi Peter,

This is an interesting experiment.

On 01/16/2013 12:59 PM, Peter Levart wrote:
I did some micro benchmarks and here are the results:

http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt

Results indicate that usage pattern: Thread.current().nextInt() is as
fast as proposed variant while the nextInt() method itself is as fast as
JDK7's, which is some 20% faster than proposed variant.
I find this hard to believe, since the baseline experiment I did in the
conceiving note in this thread actually tells otherwise:

JDK8 (baseline, 4 threads)
               TLR.nextInt():  6.4 +- 0.1 ns/op
     TLR.current().nextInt(): 16.1 +- 0.4 ns/op
          TL.get().nextInt(): 19.1 +- 0.6 ns/op

JDK8 (patched, 4 threads)
               TLR.nextInt():  6.5 +- 0.2 ns/op
     TLR.current().nextInt():  6.4 +- 0.1 ns/op
          TL.get().nextInt(): 17.2 +- 2.0 ns/op

That is, TLR.current().nextInt() is as fast as the already-acquired
TLR.nextInt() even in the baselined case, which pretty much means we hit
the lower bound for possible infrastructure overheads, and we actually
compute. Note that the changes in next() did not degrade the performance
either. Please check your microbenchmarks.

So the
alternative implementation seems to be faster and it has the following
additional benefits:

- Checks the calling thread and throws when called from invalid thread.
This is the spec change; potentially breaks the code (instead of "just"
degrading performance). I would not like to see that pushed into JDK.

- Could reinstate the padding fields (or @Contended long rnd) if needed
(the tests were done without padding)
Hardly a benefit, since Thread can be padded as well, and padding there
will yield better footprint.

-Aleksey.



Reply via email to