[
https://issues.apache.org/jira/browse/RNG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778031#comment-16778031
]
Gilles commented on RNG-72:
---------------------------
Thanks for the in-depth review of the code!
I'm fine with the "non-destructive improvements" provided that they do not
overly complicate the code wrt enhancement which they offer for normal usage.
Not generating more numbers than necessary is certainly a welcome improvement
(IIRC, I had considered it but decided to not explore it further, given the
assumed POV on "normal usage").
Actually, how useful is it to target utmost performance of construction,
whereas "use time" is supposedly always overwhelmingly larger?
Isn't it a sign of bad usage that one should be hindered by RNG construction
time, or IOW, shouldn't the RNG always be sufficiently long-lived that any
construction improvement is dwarfed?
Case in point is "TWO_CMRES" which is one of the faster generators whereas it
fares badly in this benchmark.
This bears on the second line of improvements; indeed I chose "Well44497b" in
order to have the largest pool of different seeds, and assuming long-lived
generators, it doesn't matter that it's "slow".
Also, the "seed factory" is a convenience; users that need fast construction
would probably be better off choosing the RNG that suits them better and use
that to generate seed themselves.
> 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)
