Date: Wed, 17 Nov 2021 17:03:08 -0800
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).
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).
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2021-11-17 19:03:13