Parallelisation

[ThomasASmith]

Parallelisation of C++ code is more straightforward than it used to be and Monica plans to address this at some point

[dhardy]

We had quite a bit of discussion on various ways of having parallel RNGs and keeping results reproducible in Rust: rust-random/rand#399

Yes, parallelisation is not does not have to be especially hard (with the right tools).

For OpenMalaria I would suggest replacing the random number generator first (another topic we discussed for the Rust project) and consider the parallelisation model. There are reasonable quality PRNGs requiring only 8-16 bytes (whereas Mersenne Twister uses at least 2500). This would allow storing the PRNG state per human agent at birth, which would then let human updates be made to run in parallel while producing exactly the same results (i.e. this can be used for verification).

[dhardy]

We discussed this today. There is some interest in getting this working, but it is not considered high-priority since experiments can already be parallelised by running multiple scenarios simultaneously.

Potentially we could forfeit reproducibility when running in parallel, though I do not think we need to.

@Monica-Golumbeanu doesn't currently have time to work on this but suggests using OpenMP.

[dhardy]

PR #255 has solved the RNG issues (allocating each human agent its own generator seeded from a high-quality master with no observable performance impact), but other issues remain.

Most notably, the monitoring code works by reporting events into a global table; this requires some level of thread protection; unfortunately each option has a cost:

• Use atomic variables in the table; unfortunately vector<atomic<..>> is not supported by the language and (until C++20 which isn't even standardised yet) doesn't support floating-point types; performance impact is unknown
• Use a mutex to lock the entire table when reporting; likely has a significant performance cost (though this can be minimised when running single-threaded)
• Use thread-local tables and accumulate at the end of each step or the simulation; this has a memory cost, run-time cost and code complexity cost

At this point I question the value of further work towards parallelisation given that most users are more interested in throughput performance (simulating many scenarios simultaneously).