On 03/14/2014 01:29 AM, Brian Burkhalter wrote:
On Mar 12, 2014, at 2:08 AM, Peter Levart wrote:
Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a
ThreadLocalRandom instance in a thread that did not obtain it via a
call to ThreadLocalRandom.current()…
Good point.
You could create a new BigInteger(512,*rnd*) in the static
initializer and use it to create new BigDecima(bigInteger) in
testFirstToStrin.
I simply replaced ThreadLocalRandom with Random which probably creates
a bottleneck but there is no significant difference in the results.
That's probably because the time spent computing the toString
representation initially (the concurrent part of testFirstToString
benchmark) takes much more time than computing the random number (the
synchronized/serialized part). The difference would probably show with
bigger number of threads on a suitable machine of course.
But in general it would be better to just use
"ThreadLocalRandom.current()" everywhere you use "rnd" variable. This is
precisely it's purpose - a random number generator that is never
contended. The overhead of ThreadLocalRandom.current() call is hardly
measurable by itself.
Regards, Peter
http://cr.openjdk.java.net/~bpb/6375303/Bench6375303.java
<http://cr.openjdk.java.net/%7Ebpb/6375303/Bench6375303.java>
http://cr.openjdk.java.net/~bpb/6375303/6375303-bench.html
<http://cr.openjdk.java.net/%7Ebpb/6375303/6375303-bench.html>
Thanks,
Brian
