Multiprocessing or Multithreading?

Question

I\'m making a program for running simulations in Python, with a wxPython interface. In the program, you can create a simulation, and the program renders (=calculates) it for

Answer 1

With CPython multiple threads can't execute at the same time because of the GIL: link text.

I think it's still possible that threads boost your application, e.g. a thread might block on I/O while another one does some work.

If you've never used threads, I suggest that you try them first. It will be useful in any other language, and you'll find a lot of ressources on the web. Then if you realize that you need more parallelism, you still can switch back to processes.

Answer 2

There was a good talk on multiprocessing at Pycon this year. The takeaway message was "Only use multiprocessing unless you're sure you have a problem that it will solve, that cannot be solved with threads; otherwise, use threads."

Processes have a lot of overhead, and all data to be shared among processes must be serializable (ie pickleable).

You can see the slides and video here: http://blip.tv/pycon-us-videos-2009-2010-2011/introduction-to-multiprocessing-in-python-1957019

http://us.pycon.org/2009/conference/schedule/event/31/

Answer 3

• Stackless: uses 1 cpu. "Tasklets" must yield voluntarily. The preemption option doesn't work all the time.
• Threaded: uses 1 cpu. Native threads share time somewhat randomly after running 20-100 python opcodes.
• Multiprocessing: uses multiple cpu

Update

Indepth Analysis

Use threaded for an easy time. However, if you call C routines that take a long time before returning, then this may not be a choice if your C routine does not release the lock.

Use multiprocessing if it is very limited by cpu power and you need maximum responsiveness.

Don't use stackless, I have had it segfault before and threads are pretty much equivalent unless you are using hundreds of them or more.