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
