4 ms·

Unrelated question, isn't it a bad idea to update the seed for every sample?

acadien 12y ago
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.
- Goopplesoft 12y ago
  It uses the plan 9 PRNG algo written by Ken (http://golang.org/src/math/rand/rng.go http://golang.org/src/math/rand/rng.go)
  - deleted 12y ago
    [deleted]
danbruc 12y ago
It is in multiple ways. 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.
- omni 12y ago
  It is indeed nanosecond precision. http://golang.org/pkg/time/#Time http://golang.org/pkg/time/#Time
  - danbruc 12y ago
    The value is represented with nanosecond resolution, but that does not imply that Now() will return a different value every nanosecond.
    - omni 12y ago
      You are of course technically correct. It seems the precision returned by Now may be platform-dependent. https://github.com/golang/go/blob/master/src/time/time.go#L777 https://github.com/golang/go/blob/master/src/time/time.go#L7...
reikonomusha 12y ago
It is wasteful and nullifies the benefits offered by a PRNG. For Monte Carlo simulations, it's in fact very bad practice to continually reseed a computation, as it makes them unrepeatable.
xeno42 12y ago
Additionally - Pushing the seed operation out of the loop decreased the run time for 1,000,000 samples from ~10 seconds to ~50ms on my machine.
- orting 12y ago
  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.
  - sukilot 12y ago
    (6.36 - 1) *100 = 536 ~= 540, So what distrinctiont are you trying to draw?
    - orting 12y ago
      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.
soroushjp 12y ago
Fixed, thank you :)

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.

Goopplesoft 12y ago
It uses the plan 9 PRNG algo written by Ken (http://golang.org/src/math/rand/rng.go http://golang.org/src/math/rand/rng.go)
- deleted 12y ago
  [deleted]

danbruc 12y ago

It is in multiple ways. 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.

omni 12y ago
It is indeed nanosecond precision. http://golang.org/pkg/time/#Time http://golang.org/pkg/time/#Time
- danbruc 12y ago
  The value is represented with nanosecond resolution, but that does not imply that Now() will return a different value every nanosecond.
  - omni 12y ago
    You are of course technically correct. It seems the precision returned by Now may be platform-dependent. https://github.com/golang/go/blob/master/src/time/time.go#L777 https://github.com/golang/go/blob/master/src/time/time.go#L7...

reikonomusha 12y ago

It is wasteful and nullifies the benefits offered by a PRNG. For Monte Carlo simulations, it's in fact very bad practice to continually reseed a computation, as it makes them unrepeatable.

xeno42 12y ago

Additionally - Pushing the seed operation out of the loop decreased the run time for 1,000,000 samples from ~10 seconds to ~50ms on my machine.

orting 12y ago
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.
- sukilot 12y ago
  (6.36 - 1) *100 = 536 ~= 540, So what distrinctiont are you trying to draw?
  - orting 12y ago
    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.

soroushjp 12y ago

Fixed, thank you :)