On 11/18/21 02:03, Thiago Macieira via Std-Proposals wrote:
> On Wednesday, 17 November 2021 15:24:08 PST Dimitrij Mijoski via Std-Proposals
> wrote:
>> Even if we put the entropy discussion aside, there is the performance
>> aspect. Calling random device is slow because you do a system call
>> internally to the OS, and the OS might even do some IO. The number of
>> calls to random_device should be small.
>
> Also, random_device should have an API to fill a buffer of uint32_t or
> uint64_t, instead of returning a single one.
>
> That would amortise the cost of seeding a PRNG with more than 32 bits of
> state. Aside from rand_s(), all alternatives can provide at least 64 bits of
> data and most of them can fill in buffers (and rand_s calls RtlGenRandom,
> which fills in buffers).
>

Thanks, this also was an important motivation for P0205R0. Potentially
making an individual syscall for each 32 bit integer is really annoying
if you want several of them. Even if you're convinced that 128 bits are
enough for your application, I'd much rather obtain them all at once
instead of doing four individual calls. Meanwhile, P1068R4 has suggested
a more general solution (which I'm in favor of) that would allow any
generator, not just std::random_device, to offer that optimization so
P0205R1 took this into account.

As others have mentioned several times by now (sorry for joining late),
making the standard library allow users to efficiently and conveniently
initialize any pseudo random number generator of their choice in a way
that makes each state equally likely to be the initial state should be
discussed orthogonal to the question what PRNG (with how large of an
internal state) is best suited for a given application.