Hacker News Reader

Comment by kibwen | Hacker News Reader

Personally I think it's kind of silly that we've normalized the idea of PRNGs-as-global-state. I'm not asking everyone to go Full Monad, but please just consider giving each Thing that needs access to randomness its own independent PRNG.

View on HN

The world seems full of APIs that make it easy to avoid global state. Most of my usage of randomness has been through things like rust's rand::thread_rng or Java's ThreadLocalRandom. (In fact I think even java.util.Random uses its own state: the docs call out perf issues but only if you share the same instance across threads.)

Honorable (?) mention goes to (client-side) JavaScript - it's harder to have threading issues if you only have a single thread to work with!

I think Linux has recently seen quite a lot of work on speeding up its PRNGs but something similar to what you proposed didn't end up making it into the kernel due to a few issues, and I think at the time it ended with this :

"Linus Torvalds, though, argued that none of this effort was worth it. Speeding up random-number generation, beyond a point, is not the kernel's job, he said; instead, that should be left to the C library."

https://lwn.net/Articles/919008/

I've not been following the mailing lists so I don't know if that ever changed since then. The dev (Jason Donenfeld) seemed to think there was a way to get it working without the issues that blocked the improvement from getting merged last time though.

it's not just random() - it's stdio, and malloc/free/new/delete (though some implementations use per-thread pools with added complexity)

Sounds like it’s time to go Full Monad then.

Blaming PRNGs sounds like bikeshedding when it's the hot paths in user-land that often do too much or do it badly without respecting the caches, the branch predictor, and/or compiler or don't diagonalize the problem sufficiently to break the hot section of the problem into independent steps to run concurrently and in parallel as much as possible. Some classes of problems have no known parallel solution, and that's okay and beneficial in some cases.

Also, if you feel that strongly, please don't roll your own crypto and use a CSPRNG.

if you have multiple threads working a queue of like-kinded jobs, you’ve given up the determinism of using any sort of global seed

you could pull different set lengths of pseudorandom numbers from the different seeds

That's what counter-based RNGs are for.

How does being a monad intersect with scope i'm genuinely curious

Monads allow representing which global values a function reads to or writes to in the type of the function.

Monads do not imply global values or variables.

But the stated paradigm is one thing they allow. See the Reader, Writer, and State monads.

The Random Monad in Haskell allows you to write pseudo-random code without caring where the prng comes from. It's only when the caller runs evalRand/runRand that it must provide the prng. So you can't possibly screw up the random code by sourcing a global prng even if you wanted to; rather, it's the caller that has full control over the prng.

https://hackage.haskell.org/package/MonadRandom-0.1.3/docs/C...

Reply on news.ycombinator.com