Is continuously seeding a random number generator performance intensive?

[monarch_dodra]

On Friday, 3 January 2014 at 01:43:09 UTC, Chris Cain wrote:
> So, it sounds like the OP is using the x and y coords for a 
> seed to generate a single number and he was curious to whether 
> it costs too much to reseed like this for every point.
>
> FWIW, I'm under the impression that this is a fairly common 
> strategy, but usually when I've seen this used more than one 
> number is generated at a time.

I *thought* he wanted to do something like that, but was 
surprised by the fact he wanted to reseed *per* element...

> You can still do this, in this case. For example, divide x by 
> 10 and generate 10 elements (column wise) in the noise map each 
> time and it reduces the number of reseeds by a factor of 10. 
> Some effort might be wasted, but as long as you need a decent 
> chunk of the noise map at any one point in time, this should 
> work out pretty well in practice.
>
> My biggest concern with this approach is that you must take 
> care that your usage of seeding with x and y coordinates does 
> not cause repeated elements to occur. For instance, using 
> `Random rng = Random(x + y);` will _not_ work properly (unless 
> you want strange mirroring down the diagonal in your noise 
> map). There's numerous landmines to avoid when doing something 
> like this. Some approaches may not be perfect, but depending on 
> what you're doing they may be sufficient, however.

The approach I'd take here is to eagerly generate a "uint[X / 
1000][Y / 1000]" grid, that holds randomly generated numbers, to 
be used as seeds for individual 1000*1000 blocks of the noise 
map. I don't know how good that is though in terms of 
correlation...?

Or, even better, to create a single generator of type "Gen", and 
store a "Gen[X / 1000][Y / 1000]": EG: the generator, with a 
"checkpoint" every 1_000_000 elements. This should reduce 
correlation down to 0.

AFAIK, all generators above the "linear congruential generator" 
have a period above 10^12, so this approach should be fine. The 
only issue with such an approach might be the size of the PRNG's 
themselves: XOrShift, for example, is only a few bytes big, so 
that's fine. But MT is about 700B, which is a hefty amount to 
chug along.