RFR 8020292 <was> :Re: class SplittableRandom

[Aleksey Shipilev]

On 07/12/2013 09:26 PM, Paul Sandoz wrote:
> Here is the webrev:
>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-splittable-random/webrev/

OK, early performance data follows. I've used a simple benchmark [1] to
estimate the standalone costs for getting int/long/double, as well as
the usage in trivial recursive FJP processing. Runs were with JDK 8b97,
Solaris 10, 2x8x2 SandyBridge running RHEL 5.5.

We test:
  "SR": SplittableRandom.next*
  "TLR_1": ThreadLocalRandom.current().next*
  "TLR_2": r.next* // field r = ThreadLocalRandom.current()

The results are here [2]. Notable results follow.

Standalone:
 - 64 bit: on moderately saturated machine (1, 16 threads), SR double is
marginally faster than TLR, and SR int/long is significantly faster than TLR
 - 64 bit: on fully-subscribed machine (32 threads), SR int/long/double
starts to suffer. Since this is not affected run-to-run, I don't think
this is the memory sharing effects, but most likely the execution unit
sharing
 - 32 bit: TLR is vastly faster in int/long standalone scenarios

Recursive FJP (average):
 - average times are notoriously bad for FJP tests, since outliers skew
the mean significantly; the results are inconclusive if SR is the
performance benefit over TLR (which makes sense)

Recursive FJP (sample, 95 percentile):
 - 64 bit double case: TLR_2 wins over SR, SR wins over TLR_1
 - 64 bit int case: SR wins over TLR_1 and TLR_2
 - 64 bit long case: SR tied with TLR_2
 - 32 bit double case: SR wins big time
 - 32 bit int case: SR wins over TLR_2, but loses to TLR_1
 - 32 bit long case: TLR_2 wins over SR

The conclusion is: SR is a reasonable alternative with no obvious
performance show-stoppers. That said, TLR is also reasonably fast at
this point, and further improvements to TLR will probably beat the SR or
tie it on most scenarios.

-Aleksey.

[1] http://cr.openjdk.java.net/~shade/8020292/splitrandom.tar.gz
[2] http://cr.openjdk.java.net/~shade/8020292/data/