JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks

[Brian Burkhalter]

On Oct 9, 2013, at 5:33 AM, Paul Sandoz wrote:

> Nice! 
> 
> Perhaps as a separate bug you could place that code in the JDK test area as a non-jtreg test?

Please see: 

https://bugs.openjdk.java.net/browse/JDK-8026236

The file of primes would need to be hosted elsewhere than the repository given its size.

> Tip: you can use Files.lines().map(BigInteger::new) but we don't current have a limitWhen operation so need to limit to N primes and not the content.
> 
> And... a bonus we can now go parallel and since TLR is used there is no longer the contention point as with SR, which means we go faster! 
> 
> I have added a modified version of the test code (see end of email) if you want to play. If you place this test in the JDK test area i strongly recommend using streams, it's a nice use-case we can point people to.
> 
> Here is the difference for the first 1000000 primes (with your patch applied) for parallel and sequential execution (which also includes the fixed cost of loading the primes from disk):
> 
> $ time java PrimeTest primes-50M.txt 1000000 100 true

By way of comparison here are some other results of the same test

--- SecureRandom, parallel = false --- real	3m36.360s
--- SecureRandom, parallel = true --- real	3m11.726s
--- ThreadLocalRandom, parallel = false --- real	2m34.260s
--- ThreadLocalRandom, parallel = true --- real	1m39.173s

These are of course not real benchmarks, especially as I was running on my dev system, but they are encouraging.

> 16s vs. 55s :-)

The most salient point here is clearly that my machine is *much* slower. ;-)

>> An updated webrev which differs only in having a correct Hg header is here:
>> 
>> http://cr.openjdk.java.net/~bpb/7189139/webrev.2/
>> 
>> If this looks good to go, would a Reviewer please issue an approval?
>> 
> 
> +1

Done: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/673f8045311e.

Thanks,

Brian