Question

Hey, id like to make this as fast as possible because it gets called A LOT in a program i’m writing, so is there any faster way to initialize a C++ vector to random values than:

double range;//set to the range of a particular function i want to evaluate.
std::vector<double> x(30, 0.0);
for (int i=0;i<x.size();i++) {
    x.at(i) = (rand()/(double)RAND_MAX)*range;
}

EDIT:Fixed x’s initializer.

Answer 1

Right now, this should be really fast since the loop won’t execute.

Personally, I’d probably use something like this:

struct gen_rand { 
    double range;
public:
    gen_rand(double r=1.0) : range(r) {}
    double operator()() { 
        return (rand()/(double)RAND_MAX) * range;
    }
};

std::vector<double> x(num_items);
std::generate_n(x.begin(), num_items, gen_rand());

Edit: It’s purely a micro-optimization that might make no difference at all, but you might consider rearranging the computation to get something like:

struct gen_rand { 
    double factor;
public:
    gen_rand(double r=1.0) : factor(range/RAND_MAX) {}
    double operator()() { 
        return rand() * factor;
    }
};

Of course, there’s a really good chance the compiler will already do this (or something equivalent) but it won’t hurt to try it anyway (though it’s really only likely to help with optimization turned off).

Edit2: “sbi” (as is usually the case) is right: you might gain a bit by initially reserving space, then using an insert iterator to put the data into place:

std::vector<double> x;
x.reserve(num_items);
std::generate_n(std::back_inserter(x), num_items, gen_rand());

As before, we’re into such microscopic optimization, I’m not at all sure I’d really expect to see a difference at all. In particular, since this is all done with templates, there’s a pretty good chance most (if not all) the code will be generated inline. In that case, the optimizer is likely to notice that the initial data all gets overwritten, and skip initializing it.

In the end, however, nearly the only part that’s really likely to make a significant difference is getting rid of the .at(i). The others might, but with optimizations turned on, I wouldn’t really expect them to.