[benchmark] Add SplitMix64 PRNG

[palimondo]

Very fast pseudorandom number generator with 64 bits of state, conforming to RandomNumberGenerator protocol, passing BigCrush.

See #24206 for use case.

[palimondo]

cc @rajbarik

[atrick]

Cool. Thanks.

[palimondo]

@swift-ci please smoke test and merge

[palimondo]

@swift-ci please smoke test Linux platform

[eeckstein]

Is this intended to be used by new benchmarks?
Any specific reason to add this now?
(I'm asking because unused code usually vanishes over time)

[atrick]

@eeckstein It's intended to replace Int.random in BucketSort.

It could also replace LFSR in TestUtils now. I added that to try to encourage benchmark authors not to use some platform specific, nondeterministic random, and to make sure all benchmarks used a fixed seed value, but it doesn't seem to be used anymore.

@lorentey should also probably use a PRNG from TestUtils in BreadCrumbs rather than rolling his own.

Of these three PNRG's, I don't have a preference. I originally wrote LFSR to be used as a benchmark itself, before the stdlib had any random API. Presumably @palimondo wanted something faster as a pure utility. I don't know if there's a reason that @lorentey rolled his own.

[palimondo]

I can only speculate, but IIRC Breadcrumbs was a first benchmark to use PRNG after random unification, therefore @lorentey had to roll his own implementation. He reasonably kept it local since that LCRNG was good enough for his needs, without making any claims about its suitability for other purposes.

I’m suggesting putting SplitMix64 into shared place, because it has equally minimal implementation footprint but according to its authors it also has reasonably good quality, since it passes BigCrunch tests.

@eeckstein I’ll test if we can substitute it in Breadcrumbs without altering performance results, but as @atrick said, primary motivation was to supply a common utility for use in BucketSort now and for any future benchmarks that need PRNG.

Speed per-se wasn’t that important to me, even thought I got SplitMix64‘s impl. as a side effect of studying Xoshiro family of PRNGs, which relies on it for its seed initialization. If you want, we might also add Xoshiro256** if we want something that’s ~30% faster and has longer period, but I didn’t think it’s required by any of our current use cases. It would be additional 15–20 LOC.