Hacker News Reader

Comment by ScottBurson | Hacker News Reader

Uh, you can't just drop in 'random_r' in place of 'random'. If you do that, what will happen is that you'll get the same sequence of random numbers in every thread, making the whole multithreading exercise useless!

You have to be sure to seed the generator differently in each thread, before calling 'random_r'.

View on HN

Moreover, he probably improved the single threaded version, and should re-check the scaling curve. There should be a `1 with random_r`, `2 with random_r`, and `3 with random_r`.

It's unlikely the single-threaded version was improved noticeably. Futexes are nearly zero-cost when not contended.

I left the random_r numbers with single threads out of the post for exactly this reason. Performance with random_r on a single thread was less than 3% faster, with a slightly higher variance (which I can't explain, to be honest).

Yes, absolutely. That can be done using the global state (i.e. calling rand() or random()), or is probably better done by pulling from the system entropy pool (via /dev/urandom on Linux).

Still no good; you can get spurious correlations between rng outputs on each core. You need something like L'Ecuyer RNG streams.

Well, using /dev/urandom is a vast improvement over doing nothing.

But your point is well taken. People doing serious Monte Carlo simulations should probably use a more sophisticated RNG.

It's just an example.

Reply on news.ycombinator.com