[
https://issues.apache.org/jira/browse/RNG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780465#comment-16780465
]
Gilles commented on RNG-72:
---------------------------
Since the {{SeedFactory}} can be indirectly used from different threads, I
don't think that we can do without synchronization.
{quote}
I have also just noted that if you do want to seed using a fast SplitMix64
without synchronisation then the following is possible:
RandomSource.create(RandomSource.XOR_SHIFT_1024_S, Seedfactory.nextLong());
{quote}
I don't follow: The call to {{SeedFactory}} will be synchronized, hopefully.
{quote}
* Create a RNG using a good seeding routine (the current implementation)
* Create a RNG for one time throw away usage where the expected number of
random generator calls is low. This should be seeded fast.
{quote}
How about keeping {{SeedFactory}}'s current set of methods untouched, but add a
"fast" alternative whenever it would be significantly faster than the
synchronized version (and the caller does not care that the seed would not be
as diverse), e.g.
{code}
public static int[] fastCreateIntArray(int n) {
final SplitMix64 rng = new SplitMix64(createLong()); // Seeded with
"slow" generator.
final int[] out = new int[n];
for (int i = 0; i < n; i++) {
out[i] = rng.nextInt();
}
return out;
}
{code}
?
> Create a RandomSource.create benchmark
> --------------------------------------
>
> Key: RNG-72
> URL: https://issues.apache.org/jira/browse/RNG-72
> Project: Commons RNG
> Issue Type: New Feature
> Components: simple
> Affects Versions: 1.3
> Reporter: Alex D Herbert
> Assignee: Alex D Herbert
> Priority: Minor
> Labels: performance-benchmark
> Fix For: 1.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The recommended method to construct a {{UniformRandomProvider}} is to use,
> e.g.:
> {code:java}
> import org.apache.commons.rng.UniformRandomProvider;
> import org.apache.commons.rng.simple.RandomSource;
> UniformRandomProvider rng = RandomSource.create(RandomSource.MWC_256);
> {code}
> The factory method knows the type of seed required for the constructor and
> generates one as appropriate.
> This factory method could be made more efficient, in particular:
> * Reducing synchronisation around the single source of random seed data
> * Adding knowledge of the required seed size for arrays
> * Changing internal data structures, e.g. {{Map<Class<?>,
> SeedConverter<?,?>>}} can be changed to {{Map<SeedType, SeedConverter<?,?>>}}
> using an {{EnumMap}} if a new enum {{SeedType}} was created for all the
> supported seeds (currently 4 types).
> * Add a new interface to replace {{SeedConverter<?,?>.convert()}} with a
> {{.convert(int outputArraySize)}} method to allow conversions to generate
> appropriately sized arrays. The parameter can be ignored for non-array
> conversions but could optimise array conversions.
> This ticket is to add a JMH benchmark to compare the speed of construction of
> all the providers using:
> * Their native constructor
> * {{RandomSource}} using the native seed of the correct size (calls a
> constructor using reflection)
> * {{RandomSource}} using a non native seed (requires seed conversion)
> * {{RandomSource}} using no seed (requires seed generation)
> The report will be posted here. It could be added to the user guide for
> reference.
> This work is motivated by the new {{XorShiRo}} generators in version 1.3 that
> have a native array seed size of 2, 4, or 8. The current {{RandomSource}}
> create method will generate a fixed seed of length 128 for seeding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
