There are much more active projects that do the same thing as this.<p>- IPython parallel (<a href="https://ipyparallel.readthedocs.io/en/latest/" rel="nofollow">https://ipyparallel.readthedocs.io/en/latest/</a> ) is pretty much the same idea but under active development, supports both local processes, small clusters, cloud computng, an HPC environments (SGE style supercomputing schedulers).<p>- Joblib is a great tool for common embarrassingly parallel problems - run on many cores with a one liner (<a href="https://pythonhosted.org/joblib/index.html" rel="nofollow">https://pythonhosted.org/joblib/index.html</a>)<p>- Dask provides a graph-based approach to lasily building up task graphs and finding an optimal way to run them in parallel (<a href="http://dask.pydata.org/" rel="nofollow">http://dask.pydata.org/</a>)
By my estimate, this projects seems to be old / stalled, not in active development. This notion is based on the lack of Python 3 support and the fact that majority of the activity in the forums happened in years 2006 - 2010.<p>EDIT: I was wrong, there is some activity in a different branch of the forum [1]. Last release almost two years ago.<p>[1] <a href="http://www.parallelpython.com/component/option,com_smf/Itemid,29/board,2.0" rel="nofollow">http://www.parallelpython.com/component/option,com_smf/Itemi...</a>
Most fellow python people know this already, but native compiled C/C++ code generally runs about 100x faster than interpreted CPython code for any kind of number crunching or computation. So like sonium also mentioned, definitely consider the C route also if you're at all familiar with it and you're having performance problems. Threading python wouldn't generally get you as far (perhaps 4-6x speedup on an 8 core machine). Python's C integration is very well thought out and lets you use the best of both languages, as well as gain a deep understanding of what's going on under the hood in your python programs.
I'm a daily user of Python but the parallelization efforts really make me wonder.
When things in Python are slow, its most likely something with native Python code (in contrast to e.g. Numpy).
Wouldn't it then make more sense to rewrite this in native C code which gives a speedup of two orders of magnitude instead of getting into the mess of paralellization which scales, in the best case, with number of cores?
I guess this is supposed to cure the GIL curse of threading in Python? i.e. the fact that only one thread can be running in a n interpreter process.<p>There is still the multiprocessing module which can spawn processes, so you can effectively run code in parallel. It's pain to manage though.<p>I think in the end I am grateful for no parallel threading in Python as it forces me to either do things so that they can be run in naive-parallel, or to use things that have the concurrency solved out of Python.
Wouldn't it make a lot of sense to just use Pyspark with RDDs? Latency would be relatively high, but it'd also bypass the GIL while also being more modern.
It seems to be Python's "multiprogramming" module with some extra features.<p>Python's parallelism options are "share everything (but with only one thread computing at a time)", or "share nothing" in a different process on the same machine. If you're parallelizing to get extra crunch power, neither is efficient.