在循环中使用 normal_distribution

Question

I'm wondering if there could be a problem with putting normal_distribution in a loop.

Here is the code that uses normal_distribution in this strange way:

std::default_random_engine generator;
//std::normal_distribution<double> distribution(5.0,2.0);

for (int i=0; i<nrolls; ++i) {
    std::normal_distribution<double> distribution(5.0,2.0);
    float x = distribution(generator);

}

Answer 1

Putting the normal_distribution object outside the loop may be slightly more efficient than putting it in the loop. When it's inside the loop, the normal_distribution object may be re-constructed every time, whereas if it's outside the loop it's only constructed once.

Comparison of the assembly.

Based on an analysis of the assembly, declaring distribution outside the loop is more efficient.

Let's look at two different functions, along with the corresponding assembly. One of them declares distribution inside the loop, and the other one declares it outside the loop. To simplify the analysis, they're declared const in both cases, so we (and the compiler) know that the distribution doesn't get modified.

You can see the complete assembly here.

// This function is here to prevent the compiler from optimizing out the
// loop entirely
void doSomething(std::normal_distribution<double> const& d) noexcept;

void inside_loop(double mean, double sd, int n) {
    for(int i = 0; i < n; i++) {
        const std::normal_distribution<double> d(mean, sd); 
        doSomething(d); 
    }
}
void outside_loop(double mean, double sd, int n) {
    const std::normal_distribution<double> d(mean, sd);
    for(int i = 0; i < n; i++) {
        doSomething(d); 
    }
}

inside_loop assembly

The assembly for the loop looks like this (compiled with gcc 8.3 at O3 optimization).

.L3:
        movapd  xmm2, XMMWORD PTR [rsp]
        lea     rdi, [rsp+16]
        add     ebx, 1
        mov     BYTE PTR [rsp+40], 0
        movaps  XMMWORD PTR [rsp+16], xmm2
        call    foo(std::normal_distribution<double> const&)
        cmp     ebp, ebx
        jne     .L3

Basically, it - constructs the distribution - invokes foo with the distribution - tests to see if it should exit the loop

outside_loop assembly

Using the same compilation options, outside_loop just calls foo repeatedly without re-constructing the distribution. There's fewer instructions, and everything stays within the registers (so no need to access the stack).

.L12:
        mov     rdi, rsp
        add     ebx, 1
        call    foo(std::normal_distribution<double> const&)
        cmp     ebp, ebx
        jne     .L12

Are there ever any reasons to declare variables inside a loop?

Yes. There are definitely good times to declare variables inside a loop. If you were modifying distribution somehow inside the loop, then it would make sense to reset it every time just by constructing it again.

Furthermore, if you don't ever use a variable outside of a loop, it makes sense to declare it inside the loop just for the purposes of readability.

Types that fit inside a CPU's registers (so floats, ints, doubles, and small user-defined types) oftentimes have no overhead associated with their construction, and declaring them inside a loop can actually lead to better assembly by simplifying compiler analysis of register allocation.

Answer 2

Looking at the interface of the normal distribution, there is a member called reset , who:

resets the internal state of the distribution

This implies that the distribution may have an internal state. If it does, then you definitely reset that when you recreate the object at each iteration. Not using it as intended may produce a distribution which is not normal or might be just inefficient.

What state could it be? That is certainly implementation defined. Looking at one implementation from LLVM, the normal distribution is defined around here . More specifically, the operator() is here . Looking at the code, there is certainly some state shared in between subsequent calls. More specifically, at each subsequent call, the state of the boolean variable _V_hot_ is flipped. If it is true, significantly less computations are performed and the value of the stored _V_ is used. If it is false, then _V_ is computed from scratch.

I did not look very deep into why did they choose to do this. But, looking only at the computations performed, it should be much faster to rely on the internal state. While this is only some implementation, it shows that the standard allows the usage of internal state, and in some case it is beneficial.

Later edit:

The GCC libstdc++ implementation of std::normal_distribution can be found here . Note that the operator() calls another function, __generate_impl , which is defined in a separate file here . While different, this implementation has the same flag, here named _M_saved_available that speeds up every other call.