You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider switching from 128 to 256 segments.
My gut feel is that 256 will be faster in synthetic benchmarks, but overall we are doubling our reliance of RAM and the CPU caches for a small reduction in invocations of the slow path. It would be good to quantify what that slow path reduction is, bearing in mind this would be for the new improved variant from point Xoshiro256PlusRandom.cs use xoshiro256** too ? #1 above.
Re-derive the magic constants in the source code to provide confidence they are correct. We'll probably have to do this anyway for the 128/256 segment change.
There are a few things I want to do with the Ziggurat Gaussian sampling code:
Consider switching to this faster variant:
"A modified ziggurat algorithm for generating exponentially- and normally-distributed pseudorandom numbers"
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4812161/
Consider switching from 128 to 256 segments.
My gut feel is that 256 will be faster in synthetic benchmarks, but overall we are doubling our reliance of RAM and the CPU caches for a small reduction in invocations of the slow path. It would be good to quantify what that slow path reduction is, bearing in mind this would be for the new improved variant from point Xoshiro256PlusRandom.cs use xoshiro256** too ? #1 above.
Re-derive the magic constants in the source code to provide confidence they are correct. We'll probably have to do this anyway for the 128/256 segment change.