[Python-ideas] solving multi-core Python
ericsnowcurrently at gmail.com
Thu Jun 25 00:56:17 CEST 2015
On Wed, Jun 24, 2015 at 10:28 AM, Sturla Molden <sturla.molden at gmail.com> wrote:
> On 24/06/15 07:01, Eric Snow wrote:
>> Well, perception is 9/10ths of the law. :) If the multi-core problem
>> is already solved in Python then why does it fail in the court of
>> public opinion. The perception that Python lacks a good multi-core
>> story is real, leads organizations away from Python, and will not
>> improve without concrete changes.
> I think it is a combination of FUD and the lack of fork() on Windows. There
> is a lot of utterly wrong information about CPython and its GIL.
Thanks for a clear summary of the common misunderstandings. While I
agreed with your points, they are mostly the same things we have been
communicating for many years, to no avail. They are also oriented
toward larger-scale parallelism (which I don't mean to discount).
That makes it easier to misunderstand.
Why? Because there are enough caveats and performance downsides (see
Dave Beazley's PyCon 2015 talk) that most folks stop trying to
rationalize, throw their hands up, and say "Python concurrency stinks"
and "you can't *really* do multicore on Python". I have personal
experience with high-profile decision makers where this is exactly
what happened, with adverse consequences to support for Python within
To change this perception we need to give folks a simpler, performant
concurrency model that takes advantage of multiple cores. My proposal
is all about doing at least *something* that makes Python's multi-core
story obvious and undeniable.
*That* is my entire goal with this proposal. Clearly I have opinions
on the best approach to achieve that in the 3.6 timeframe. :)
However, I am quite willing to investigate all the options (as I hope
this thread demonstrates).
So, again, thanks for the feedback and insight. You've provided me
with plenty of food for thought.
More information about the Python-ideas