2) 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 #1 above.
3) 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:
1) 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/
2) 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 #1 above.
3) 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.