commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RNG-72) Create a RandomSource.create benchmark
Date Fri, 01 Mar 2019 13:25:00 GMT

    [ https://issues.apache.org/jira/browse/RNG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781667#comment-16781667
] 

Gilles commented on RNG-72:
---------------------------

{quote}Something like this (totally untested) idea:
{quote}
Yes.
 I think that synchronization is required within the "if (rng == null)" to avoid a race condition.
{quote}It should only re-seed when on a new thread.
{quote}
This is automatically taken care of by method "create" (not passing a seed to it).

And we should highlight that it is for "throw-away" use, not truly multi-thread processing
(as there is the chance that sequences of the same RNG will overlap).

The next step would be to provide the ["splittable"|https://docs.oracle.com/javase/8/docs/api/java/util/SplittableRandom.html]
feature.

> 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)

Mime
View raw message