Open wrh2 opened 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.
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
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
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
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.
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.