I am sorry but I don’t understand the work on the Random module.
In a parallel program: you must use Random.State and properly initialize the state of each PRNG
at the start of each worker thread (or process).
Hence, I don’t see the need for a “parallel Random module”.
But maybe there is something I don’t quite get.
Suddenly requiring the explicit use of Random.State for all OCaml programs will be a break of backward compatibility (which is a major design goal of OCaml 5).
Contrarily, using a domain-local state for the implicit Random state combined with a splittable PRNG achieves both backward compatibility and good statistical properties.
2 Likes
Actually it’s not at all clear how to do this. If you use “self-initialization” (from /dev/random etc.) for each worker, it’s fine. But if you want to use a fixed seed for reproducibility, how do you decide which seed to pass to each worker?
- If you just pass, say, the worker number as seed, you will get poor randomness (spawning workers once, they terminate, then spawn workers again, naively you reuse the same seeds!).
- If you use a global reference to increment the seeds, you get non-determinism if workers can themselves spawn workers.
- If you ask your current RNG state to provide the seed, it’s not clear at all that you get good statistical properties (you may end up with correlated streams for the different workers).
The property that “there exists a clear way to seed a new RNG state from my current RNG state with good statistical properties” is called “splitting”, and it requires a PRNG algorithm where the quality of the splitting operation has been studied.
3 Likes
Ok, so a splitting RNG looks like a useful thing indeed.
Usually, in a parallel program, I consider the top-level (seeded) RNG as seed stream
initializing all the other RNGs, instead of a source of actual randomness that is used directly.
multicore just went on hackernews PR to Merge Multicore OCaml | Hacker News
1 Like
Probably also worth to lock the PR and limit discussion only for contributors, otherwise expect a lot of spam.
2 Likes
Blocking out visitors seems woeful and going against the spirit of open source to me - is spam really such a problem in this particular case? I have no experience, how bad is it?
There’s plenty of room for discussion and questions here, on HN, on reddit, etc. Limiting discussion on the PR is only “blocking out visitors” in the sense of preventing extraneous comments; it’s not like it’s blocking anybody from reading the PR or the discussion. The second comment on the PR is already a spam review.
2 Likes
Since the initial spam comments there have been no further spam comments. I think there were a total of 2 spam comments, 1 of which has now been removed. This is not an overwhelming number.
Closing comments to only contributors means that someone in the wider OCaml community (who may not have contributed to the ocaml compiler) may be prevented from adding a comment or question. We should leave it open for now is my opinion!
If the spam becomes unmanageable then definitely close for comments!
(I predict there might be some spam when the PR is merged though!)
1 Like
By the way, it’s possible to vote for the MSVC C11 atomics support here: Visual Studio Feedback
Voted! Thanks @XVilka for that link. Hope everyone bumps it up.