Floating point random benchmark

[NevinBR]

In preparation for #33455, this PR adds benchmarks for generating random floating-point numbers in the interval 0..<1.

[stephentyrone]

IIRC, newly added tests should not have a legacyFactor.

[NevinBR]

I’m not an expert in this area, I was just copying the existing benchmarks with the intention and hope that the results would be directly comparable therewith.

[NevinBR]

Okay, I’ve removed the legacy factors from the new benchmarks.

[stephentyrone]

As long as we're adding more tests here, I would like to also add the following cases:

• an exact binade; 1 ..< 2 is fine.
• a ragged example that's unbalanced around zero. Something like -(1.0.nextDown) ..< 0.126 will suffice.

[shahmishal]

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

• How to change the base branch: (Link)
• More detail about the branch update: (Link)

[NevinBR]

As long as we're adding more tests here, I would like to also add the following cases:

• an exact binade; 1 ..< 2 is fine.
• a ragged example that's unbalanced around zero. Something like -(1.0.nextDown) ..< 0.126 will suffice.

Okay, I’ve added benchmarks for those ranges.

I also notice that most of these functions are identical except for the range, the RNG, and the number of iterations. So I’m thinking of making a helper function to avoid the repetition. I’m not super familiar with benchmarking though—is there any reason I shouldn’t do that?

[stephentyrone]

Okay, I’ve added benchmarks for those ranges.

Thank you!

I also notice that most of these functions are identical except for the range, the RNG, and the number of iterations. So I’m thinking of making a helper function to avoid the repetition. I’m not super familiar with benchmarking though—is there any reason I shouldn’t do that?

I think that's perfectly reasonable. Do make sure that it doesn't fall off a performance cliff, since we want to be benchmarking the RNG and transform, not the benchmark overhead, but I don't expect that it will.

[NevinBR]

Does this look like a good approach?

@inline(never)
public func run_RandomDoubleUnitDef(_ N: Int) {
  randomDoubleHelperDef(N, 0..<1)
}

@inline(never)
public func run_RandomDoubleBinadeDef(_ N: Int) {
  randomDoubleHelperDef(N, 1..<2)
}

@inline(never)
public func run_RandomDoubleAsymDef(_ N: Int) {
  let range = -(1.0.nextDown) ..< 0.126
  randomDoubleHelperDef(N, range)
}

@inline(__always)
private func randomDoubleHelperDef(
  _ N: Int, _ range: Range<Double>, reps: Int = 1_000
) {
  for _ in 0 ..< N {
    var x = 0.0
    for _ in 0 ..< reps {
      x += Double.random(in: range)
    }
    blackHole(x)
  }
}

(And similar for LCG)

[stephentyrone]

Seems reasonable to me!