commons-issues mailing list archives

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


Alex D Herbert commented on RNG-72:

{quote}Hence, how about providing a convenience class that would store one {{ThreadLocal<UniformRandomProvider>}} per
RNG implementation

Something like this (totally untested) idea:

public final class ThreadLocalRandomSource {

    private static EnumMap<RandomSource, ThreadLocal<UniformRandomProvider>> sources
        new EnumMap<RandomSource,

    private static class ThreadLocalRNG extends ThreadLocal<UniformRandomProvider> {
        final RandomSource source;

        ThreadLocalRNG(RandomSource source) {
            this.source = source;

        protected UniformRandomProvider initialValue() {
            return RandomSource.create(source);

    public static UniformRandomProvider current(RandomSource source) {
        ThreadLocal<UniformRandomProvider> rng = sources.get(source);
        if (rng == null) {
            rng = new ThreadLocalRNG(source);
            sources.put(source, rng);
        return rng.get();

> Create a RandomSource.create benchmark
> --------------------------------------
>                 Key: RNG-72
>                 URL:
>             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
>  * {{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

View raw message