Andrey Semashev wrote:
On 11/05/17 16:00, Peter Dimov via Boost wrote:
James E. King, III wrote:
In other words, the existing implementation may be optimal using a PRNG.
This depends on your definition of optimality. If speed is more important than not having UUID collisions, sure, it's optimal.
Mersenne twister has a very long period - probably longer than any given application can reasonably run to generate UUIDs, let alone a single random_generator instance.
In general when random numbers are concerned, the best default option is to use crypto-secure numbers if you can afford it, because doing otherwise may have security implications. You could have an active attacker guessing the output of the PRNG given sufficient amount of output - which he'll have if you generate 50M UUIDs per second.
To eliminate even the slightest possibility of UUID collisions, you can re-seed the Mersenne twister PRNG periodically.
This will reduce or eliminate its performance advantage.
And performance of generating UUIDs can be significant in some circumstances. UUIDs are typically used as various resource identifiers (think sessions, users, etc.), so poor performance can limit the rate of allocation of such resources.
Sure. As I said, if speed is more important than quality, it's optimal to use a seeded-once Mersenne twister, and the option to do so will not be going away. When it isn't, it isn't. (I've trouble imagining a scenario in which you won't run out of resources if you allocate 50M resource identifiers per second, but let's suppose one exists, for the sake of argument.)