Re: Boost vs Std library features

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2023-11-30 16:14:07

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