First, you are wasting cycles and with so little work to do before reseeding as in the code shown it probably matters quite a bit.
Second, some random number generators need some warm-up time producing lower quality random numbers at the beginning.
Third, if you are reseeding faster than your seed changes, you will repeatedly consume the same sequence of random numbers. I am not sure what the resolution of Now() is, but unless it is on the order of nanoseconds this will heavily affect the shown implementation.
If the resolution is one millisecond and it took 15 seconds to execute on a single thread, then the generated random values changed only every 74 iterations.
That is nice illustration of premature optimization. Instead of thinking "Lets parallelize", one should measure and find out what causes performance problems. Should one choose to go down the parallel path, it's a good idea to test if hyper threading degrades performance. In my experience it can be expensive use more than the physical cores.
edit:
Another issue is that I really dont like when people present speedup in %. How should 540% speedup be interpreted? It makes more sense as a ratio, so we find sequential/parallel = 10067483333/1583584841 ~= 6.36. So the parallel version achieves a speedup factor of 6.36.
Yes I can do basic arithmetic. My point is that the ratio is easy to interpret, the program ran 6.36 times faster. The only reason I can think of for giving a percentage is to make it sound more impressive.
Updating the seed is extra pointless operations but if your PRNG is 'good' it shouldn't cause major numerical problems.
Besides the author is only sampling the PRNG 1 million times, this is hardly enough to stumble upon any periodicity in a modern PRNG. I have absolutely no idea if the PRNG provided by Go is any good or what method it is based off of.
First, you are wasting cycles and with so little work to do before reseeding as in the code shown it probably matters quite a bit.
Second, some random number generators need some warm-up time producing lower quality random numbers at the beginning.
Third, if you are reseeding faster than your seed changes, you will repeatedly consume the same sequence of random numbers. I am not sure what the resolution of Now() is, but unless it is on the order of nanoseconds this will heavily affect the shown implementation.
If the resolution is one millisecond and it took 15 seconds to execute on a single thread, then the generated random values changed only every 74 iterations.