3 ms·
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 conside
by kibwen 2y ago
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.
- Taniwha 2y agoit's not just random() - it's stdio, and malloc/free/new/delete (though some implementations use per-thread pools with added complexity)
- reverius42 2y agoSounds like it’s time to go Full Monad then.
- wumbo 2y agoif 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
- owlbite 2y agoThat's what counter-based RNGs are for.
- wging 2y agoThe 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!
- darby_nine 2y agoHow does being a monad intersect with scope i'm genuinely curious
- lalaithion 2y agoMonads allow representing which global values a function reads to or writes to in the type of the function.
- darby_nine 2y agoMonads do not imply global values or variables.
- anyfoo 2y agoBut the stated paradigm is one thing they allow. See the Reader, Writer, and State monads.
- yazzku 2y agoThe 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/Control-Monad-Random.html https://hackage.haskell.org/package/MonadRandom-0.1.3/docs/C...
- hi-v-rocknroll 2y agoBlaming 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.
- mardifoufs 2y agoI 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/ 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.