search

rwesson / NEAT

Empirical analysis of ionised nebulae, with uncertainty propagation
GNU General Public License v3.0
9 stars 5 forks source link

Parallelisation #3

Closed rwesson closed 8 years ago

rwesson commented 12 years ago

Users could have the option to use more than one processor if they wish. We may need to think about our random number generator: see http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fNUMBER.html

pscicluna commented 12 years ago

As I said in the email, I'll get started on this ASAP.

The Mersenne Twister seems to be the weapon of choice for MC RT routines, and has incredibly long periodicity. The original paper is http://dl.acm.org/citation.cfm?id=272995 but there's a C routine available that we can integrate once we find it.

The same authors proposed a system to allow dynamic creation of RNGs for parallel applications which is descriped here http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf with accompanying C routine in the appendix.

Using the MT would be good for the long period, but I think the main problem we would have would actually be the slowdown from each thread trying to call a single RNG.

pscicluna commented 12 years ago

Further to the previous, if we want to use MT, i think everything we need is here http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

rwesson commented 8 years ago

When we were trying this before, it was a nightmare with file reading within the main loop. We've long since moved that out, so parallelisation is now easy to implement and I've parallelised the main loop with openmp. Still need to decide if RANDOM_NUMBER is OK or if we should use the MT PRNG.

c7846978aa6a88879bbb7282d050bdd3852eeed0

rwesson commented 8 years ago

I experimented with a ziggurat parallel RNG and found no benefit, even though gfortran's algorithm is about 4 times slower than a ziggurat algorithm in serial mode. Randomisation takes up very little of the run time so thread contention seems not to be an issue.