Author: Matti Picus <matti.pi...@gmail.com>
Date: 2017-08-12 22:34 +0300
Log: suggest some wording/editorial changes
diff --git a/blog/draft/remove-gil.rst b/blog/draft/remove-gil.rst
@@ -3,31 +3,33 @@
-Discussions about the infamous Global Interpreter Lock have been around for a
-in the Python community. There has been various attempts at removing it:
-some were successful, like e.g. in Jython or IronPython with the help of the
platform, and some yet to bear fruit, like `gilectomy`_. Since our `February
sprint`_ in Leysin,
-we've been on-and-off tackling directly the topic of GIL removal in the PyPy
+The Python community has been discussing removing the Global Interpreter Lock
+a long time.
+There have been various attempts at removing it:
+Jython or IronPython successfully removed it with the help of the underlying
+platform, and some have yet to bear fruit, like `gilectomy`_. Since our
`February sprint`_ in Leysin,
+we have experimented with the topic of GIL removal in the PyPy project.
We believe that the work done in IronPython or Jython can be reproduced with
-only a bit more effort. Compared to that, removing the GIL in CPython is a much
+only a bit more effort in PyPy. Compared to that, removing the GIL in CPython
is a much
harder topic, since it also requires tackling the problem of multi-threaded
-counting. See the section below for further discussions.
+counting. See the section below for further details.
.. _`February sprint`:
-As we announced at EuroPython, what we have got so far is a GIL-less PyPy
-which can run **very simple** multi-threaded programs which are nicely
-parallelized. At the moment, non-simple programs most likely segfaults: the
+As we announced at EuroPython, what we have so far is a GIL-less PyPy
+which can run **very simple** multi-threaded, nicely parallelized, programs.
+At the moment, more complicated programs probably segfault. The
remaining 90% (and another 90%) of work is with putting locks in strategic
-places so PyPy does not segfault when you try to do concurrent accesses to
+places so PyPy does not segfault during concurrent accesses to
-Since such work would complicate the code base and our day-to-day work,
-we would like to judge the interest on the community and the commercial
+Since such work would complicate the PyPy code base and our day-to-day work,
+we would like to judge the interest of the community and the commercial
partners to make it happen (we are not looking for individual
donations at this point). We estimate a total cost of $50k,
out of which we already have backing for about 1/3 (with a possible 1/3
extra from the STM money, see below). This would give us a good
-shot at delivering a good proof of concept of working PyPy no-GIL. If we can
get a $100k
+shot at delivering a good proof-of-concept working PyPy with no GIL. If we can
get a $100k
contract, we will deliver a fully working PyPy interpreter with no GIL as a
possibly separate from the default PyPy release.
@@ -36,42 +38,45 @@
* What would the plan entail?
-We've already done the work on Garbage Collector to allow doing multi-
+We've already done the work on the Garbage Collector to allow doing multi-
threaded programs in RPython. "All" that is left is adding locks on mutable
-data structures everywhere in the PyPy codebase. Since it'll significantly
-our workflow, we need to see real interest in that topic, backed up by
-commercial contracts, otherwise we're not going to do it.
+data structures everywhere in the PyPy codebase. Since it would significantly
+our workflow, we require real interest in that topic, backed up by
+commercial contracts in order to justify the added maintenance burden.
-* Why the STM effort did not work out?
+* Why did the STM effort not work out?
STM was a research project that proved that the idea is possible. However,
the amount of user effort that is required to make programs run in a
parallelizable way is significant, and we never managed to develop tools
-that would help in doing so. At the moment we're not sure if more manpower
+that would help in doing so. At the moment we're not sure if more work
spent on tooling would improve the situation or if the whole idea is really
-The approach also ended up being a significant overhead on single threaded
+The approach also ended up adding significant overhead on single threaded
so in the end it is very easy to make your programs slower. (We have some
left in the donation pot for STM which we are not using; according to the
could declare the STM attempt failed and channel that money towards the present
GIL removal proposal.)
-* Would subinterpreters not be a better idea?
+* Wouldn't subinterpreters be a better idea?
Python is a very mutable language - there are tons of mutable state and
basic objects (classes, functions,...) that are compile-time in other
language but runtime and fully mutable in Python. In the end, sharing
things between subinterpreters would be restricted to basic immutable
-data structures, which defeats the point: it has the same problems as
-the approach of having multiple processes and no additional benefits.
-We believe that this is not viable without seriously impacting the
+data structures, which defeats the point. Subinterpreters suffers from the
same problems as
+multiprocessing with no additional benefits.
+We believe that reducing mutability to implement subinterpreters is not viable
without seriously impacting the
semantics of the language (a conclusion which applies to many other
* Why is it easier to do in PyPy than CPython?
-Removing the GIL in CPython has two problems - how do we guard access to
-data structures with locks and what do we do with reference counting that needs
-to be guarded. PyPy only has the former problem; the latter doesn't exist,
+Removing the GIL in CPython has two problems:
+- how do we guard access to mutable data structures with locks and
+- what to do with reference counting that needs to be guarded.
+PyPy only has the former problem; the latter doesn't exist,
due to a different garbage collector approach. Of course the first problem
is a mess too, but at least we are already half-way there. Compared to Jython
or IronPython, PyPy lacks some data structures that are provided by JVM or
pypy-commit mailing list