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/
