psas / roll-control

Math, data, and algorithms for our canard roll control setup
GNU General Public License v3.0
6 stars 4 forks source link

Multiprocess Monte Carlo #6

Open wrh2 opened 9 years ago

wrh2 commented 9 years ago

It would be nice to make the monte carlo tests happen with multiprocess to speed up computation time. This is something I will start working on.

wrh2 commented 9 years ago

I assumed that this issue would be a little more simple and straight-forward than it really is. My initial thoughts were that I'm doing a lot of computations so wouldn't it be nice to get some extra help from the other cores on whatever machine my process is on. However, this is a little narrow sighted so I've done some research to augment my understanding of multithreading and multiprocessing. My findings are below.

Difference between multi-threading and multi-processing:

The threading module uses threads, the multiprocessing uses processes. The difference is that threads run in the same memory space, while processes have separate memory. This makes it a bit harder to share objects between processes with multiprocessing. Since threads use the same memory, precautions have to be taken or two threads will write to the same memory at the same time. This is what the global interpreter lock is for. Spawning processes is a bit slower than spawning threads. Once they are running, there is not much difference. source: http://stackoverflow.com/a/3044626/3958521

Some of the advantages to using multi-processing:

The Multiprocessing library actually spawns multiple operating system processes for each parallel task. This nicely side-steps the GIL, by giving each process its own Python interpreter and thus own GIL. Hence each process can be fed to a separate processor core and then regrouped at the end once all processes have finished. source: https://www.quantstart.com/articles/Parallelising-Python-with-Threading-and-Multiprocessing

Separate memory space, code is usually straightforward, takes advantage of multiple CPUs & cores, avoids GIL (Global Interpreter Lock) limitations for cPython, eliminates most needs for synchronization primitives unless if you use shared memory (instead, it's more of a communication model for IPC), child processes are interruptible/killable, python multiprocessing module includes useful abstractions with an interface much like threading.Thread, a must with cPython for CPU-bound processing. source: http://stackoverflow.com/a/3046201/3958521

Some of the drawbacks to using multi-processing:

Spawning extra processes introduces I/O overhead as data is having to be shuffled around between processors. This can add to the overall run-time. However, assuming the data is restricted to each process, it is possible to gain significant speedup. Of course, one must always be aware of Amdahl's Law! source: https://www.quantstart.com/articles/Parallelising-Python-with-Threading-and-Multiprocessing

IPC a little more complicated with more overhead (communication model vs. shared memory/objects), Larger memory footprint. source: http://stackoverflow.com/questions/3044580/multiprocessing-vs-threading-python?rq=1

What all this means for this issue

As it is right now, the prototype I am using for monte carlo tests is not well suited for multiprocessing. The data is not restricted to each process so it actually adds more overhead. My initial stab at making the prototype utilize multi-processing seems to agree with this hypothesis. However, before I push the code to github I will conduct more testing and research to confirm.