Author: Matti Picus <matti.pi...@gmail.com>
Branch: extradoc
Changeset: r5830:c40625c68b87
Date: 2017-08-12 22:34 +0300
http://bitbucket.org/pypy/extradoc/changeset/c40625c68b87/

Log:    suggest some wording/editorial changes

diff --git a/blog/draft/remove-gil.rst b/blog/draft/remove-gil.rst
--- a/blog/draft/remove-gil.rst
+++ b/blog/draft/remove-gil.rst
@@ -3,31 +3,33 @@
 
 Hello everyone.
 
-Discussions about the infamous Global Interpreter Lock have been around for a 
while
-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 
project.
+The Python community has been discussing removing the Global Interpreter Lock 
for
+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 
reference
-counting. See the section below for further discussions.
+counting. See the section below for further details.
 
 .. _`February sprint`: 
https://morepypy.blogspot.it/2017/03/leysin-winter-sprint-summary.html
 
-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
 data structures.
 
-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 
release,
 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 
complicate
-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 
complicate
+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 
doomed.
-The approach also ended up being a significant overhead on single threaded 
programs,
+The approach also ended up adding significant overhead on single threaded 
programs,
 so in the end it is very easy to make your programs slower.  (We have some 
money
 left in the donation pot for STM which we are not using; according to the 
rules, we
 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
 approaches too).
 
 * Why is it easier to do in PyPy than CPython?
 
-Removing the GIL in CPython has two problems - how do we guard access to 
mutable
-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 
.NET,
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit

Reply via email to