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 you. Rendering can be very time-consuming sometimes.

When the user starts a simulation, and defines an initial state, I want the program to render the simulation continuously in the background, while the user may be doing different things in the program. Sort of like a YouTube-style bar that fills up: You can play the simulation only up to the point that was rendered.

Should I use multiple processes or multiple threads or what? People told me to use the multiprocessing package, I checked it out and it looks good, but I also heard that processes, unlike threads, can't share a lot of information (and I think my program will need to share a lot of information.) Additionally I also heard about Stackless Python: Is it a separate option? I have no idea.

Please advise.

Answer 1

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 2

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 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.

Answer 4

If you would like to read a lengthy discussion of multi-threading in Mozilla, consider having a look at this discussion which started in 2000. The discussion doesn't necessarily answer your question. However, it's an indepth discussion that I believe is interesting and informative, which I suggest may be quite valuable because you've asked a difficult question. Hopefully it'll help you make an informed decision.

Incidentally, several members of the Mozilla project (notably Brendan Eich, Mozilla's CTO and the creator of JavaScript) were quite critical of multi-threading in particular. Some of the material referenced here, here, here, and here supports such a conclusion.

Hope that helps and good luck.

Answer 5

It sounds like you'd want threading.

The way you described it, it sounded like there was one single thing that actually took a lot of CPU...the actual running of the simulation.

What you're trying to get is more responsive displays, by allowing user interaction and graphics updates while the simulation is running. This is exactly what python's threading was built for.

What this will NOT get you is the ability to take advantage of multiple cores/processors on your system. I have no idea what your simulation looks like, but if it is that CPU intensive, it might be a good candidate for splitting up. In this case, you can use multiprocessing to run separate parts of the simulation on separate cores/processors. However, this isn't trivial...you now need some way to pass data back and fourth between the processes, as the separate processes can't easily access the same memory space.

Answer 6

I always prefer multiple threads for simplicity, but there is a real issue with affinity. There is no way (that I know of) to tell Python's threading implementation to bind to a specific processor. This may not be an issue for you, it doesnt sound like it should be. Unless you have a good reason not to, it sounds like your problem can be solved easily with Python's threading implementation.

If you do decided on using processed, sharing information between sub processes can be accomplished in several ways: tcp/udp connections, shared memory or pipes. It does add some overhead and complexity.