On 30/11/2023 00:03, Peter Dimov via Boost wrote:
On that other axis though, <random> is a complete design failure. One needs the ability to copy states, serialise and deserialise states, and to get identical output on all architectures and platforms for a given starting state.
One also must not have an engine perform 20x worse on one platform than another if one is to write usefully portable code.
I don't understand your objections, sorry.
Are you saying that the generators in <random> don't offer the ability to copy, serialize, deserialize and give identical output? Because they do.
They do within the same execution of a program, but not across executions, or across standard libraries, or across architectures. Given its simplicity, I have never understood how a linear congruential engine's state couldn't have been given that added guarantee. I don't know why all PRNGs aren't required to be TriviallyCopyable and be noexcept on all functions and cannot block (i.e. no dynamic memory allocation allowed). Then I could send a PRNG state down a pipe, for example. Or I could call the PRNG from an async signal handler situation. That latter use case might sound unlikely, but it's more useful than you'd think if you're writing async signal handler code.
Which engine performs 20x worse?
I came badly unstuck with mt19937 one time. On one architecture it was 20x slower AND produced completely different output for a specific seed. Reading https://eel.is/c++draft/rand.eng.mers however, I believe that was non-conforming to the standard, and it was a long time ago now. So I'm going to chalk that up to bad QoI back in the day. Obviously there are much better quality and faster PRNGs than mt19937 nowadays, and it's a shame they're not in <random>, but for that somebody would have to write a paper. I think it's long overdue for common crypto PRNGs too. Niall