commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Rng] Merge outstanding PRs for construction speed baseline
Date Mon, 11 Mar 2019 23:54:34 GMT
Le ven. 8 mars 2019 à 18:12, Alex Herbert <> a écrit :
> Hi,
> I'd like to start on improving the methods in rng-simple to create the
> RandomSource.
> There are a few PRs outstanding but I think the discussion on this list
> was that the new XoShiRo generators are OK. So I would like to merge the
> following PRs:
> RNG-82: Add XorShift1024StarPhi generator

See other thread.

> RNG-70: Add new XoShiRo generators


> Then use master to set a baseline for the construction speed. This can
> be used to compare against the latest code to see how much the changes
> have improved construction speed. Given the work will have a big effect
> on generators with small state it would be good to have the new
> generators in the baseline.

IIUC, "big effect" only when constructing and throwing quickly very
many objects.
The doc should make it clear that it's not the "nominal" use-case.

> I note that the only tags in git are for releases. So the baseline can
> be just a commit Id and I'll add it to the benchmark Jira RNG-72 for
> reference.
> There are also some other PRs to be discussed:
> RNG-81: NumberFactory to sample all rationals between 0 and 1.
> This one changes to the implementation in Open JDK for float and double
> generation. I think this is OK to merge.

[No promise of reproducibility for "derived" types.]

> It won't effect the baseline
> but is good to get it into the next release.
> RNG-78: Added a ThreadLocalRandomSource.
> This works as a proof of concept. But it is all new files and so I'm
> happy to leave that until it is decided exactly if and where to put it.

Would there be a better place than in package "o.a.c.rng.simple"?

> RNG-76: Added primitive long constructor to SplitMix64
> This is something that will effect the benchmark so I'll merge it after.
> It is a trivial change with a noticeable performance gain by avoiding
> auto-boxing of the long seed.

IIRC, there is some developer doc that refer to having a single
constructor.  But I do not recall the reason.


> Regards,
> Alex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message