Re: [boost] Removing auto_ptr/etc. from Boost

Subject: Re: [boost] Removing auto_ptr/etc. from Boost
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-19 14:19:38

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.