On Thursday 19 March 2015 18:03:13 Peter Dimov wrote:
Andrey Semashev wrote:
Looking at Boost.Random, creating RNG involves seed generation, which is probably one or several syscalls, let alone any possible resource allocations.
Creating what type of RNG?
I was looking at random_device. Now that I look at other generators, they don't use it, so my worries are probably unfounded.
This has to be done on each call to shuffle, if I understand correctly.
Well, it depends, you can keep the URNG around if you like. You don't have to recreate it before each call.
Again, I was mistaken - seeing rvalue reference in the shuffle interface I assumed it had to be rvalue. I would have to deal with thread safety myself though.
Compare that with rand(), which is presumably purely computational and never fails.
I would expect rand() to take a lock (or use an atomic compare/exchange) under implementations that don't make it thread-specific, so it should be slower than a simple local RNG.
On Linux rand() is not thread safe in the sense that its result is not predictable, which is fine. On Windows rand() uses TLS. Not sure about other systems.
Even a thread-local rand() should be slightly slower, in principle.
Why? On Windows and Linux TLS is implemented as access through fs: qualified pointer, on other systems I would expect something similar or, at the worst, double indirection (TLS key is an index in an array of pointers, for example). It should be faster than creating RNG (even a simpler one than random_device) and comparable to referencing an existing one, given that such a reference can be trivially obtained.