This is a very general question that is mostly just conceptual. I was thinking about testing the random number generator to see its effectiveness at following a uniform distribution over some x values (ex 6 for a dice roll). Doing this in a simple loop is how I have it now, but I was thinking about multithreading the simulation.
I was wondering if this would give me any speedup since I would only have one random number generator shared between all threads with semaphore protection (needed to ensure no two threads access and generate random numbers at the same time meaning duplication of results).
Since each thread would hardly have other operations (just if statements for checking and incrementing x) would threading it even give me faster results, or will the dependency on one random number generator mean it would be essentially the same as a single thread?
In theory you should see an increase in performance, at least until the number of threads equals the number of cores in use. However, in reality, you’ll be adding code (and therefore execution time) to handle the multithreading infrastructure, and if the bulk of each thread’s time is spent waiting for a slow RNG you may see a decrease in performance.
On the other hand, you may be able to improve performance with some cleverness. For example, you might have one task dedicated to generating random numbers, and if you’re only looking for values from 1 to 6, you may be able to generate more than one value from each result from the RNG. You could put those values into a queue and let the other tasks read from the queue. Of course, you’d have to be careful that your optimizations don’t alter the distribution of the RNG.
Unless the idea of counting execution cycles excites you, the best way to find your answer is by trying it. And it’s always educational to use a profiler to find out where most of the time is spent–this is notoriously difficult for humans to get right through intuition alone, and even experienced developers are often surprised by the results.