4 ms·
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 th
by ScottBurson 12y ago
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'.
- frozenport 12y agoMoreover, 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`.
- onestone 12y agoIt's unlikely the single-threaded version was improved noticeably. Futexes are nearly zero-cost when not contended.
- mjb 12y agoI 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).
- Dylan16807 12y agoIt's just an example.
- mjb 12y agoYes, 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).
- mbq 12y agoStill no good; you can get spurious correlations between rng outputs on each core. You need something like L'Ecuyer RNG streams.
- ScottBurson 12y agoWell, 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.