Author: Armin Rigo <ar...@tunes.org> Branch: extradoc Changeset: r4158:5aa830ab48b8 Date: 2012-03-20 18:39 +0100 http://bitbucket.org/pypy/extradoc/changeset/5aa830ab48b8/
Log: Update as a two-parts talk. diff --git a/talk/ep2012/stm/abstract.rst b/talk/ep2012/stm/abstract.rst --- a/talk/ep2012/stm/abstract.rst +++ b/talk/ep2012/stm/abstract.rst @@ -1,30 +1,38 @@ -Kill the GIL..? -=============== +PyPy: status and GIL-less future +================================ -The GIL, or Global Interpreter Lock, is a well-known issue for Python -programmers that want to have a single program using the multiple cores -of today's machines. +In the first part of the talk we will present the current status and +speed of PyPy, the Python interpreter written in Python. -This talk is *not* about writing a GIL-less Python interpreter; although -hard, this has been done before, notably in Jython. The real issue is -that writing each and every multi-threaded Python programs is hard too. -The ``threading`` module offers locks in several variants, conditions, -events, semaphores... But using them correctly without missing one case -is difficult, impossible to seriously test, often impossible to retrofit -into existing programs, and arguably doesn't scale. (Other solutions -like the ``multiprocessing`` module are at best workarounds, suffering -some of the same issues plus their own ones.) +The second part of the talk is about one particular feature whose +development is in progress in PyPy: Automatic Mutual Exclusion. +What it is needs some explanation: -Instead, this talk is about an alternate solution: a minimal thread-less -API that lets programs use multiple cores, without worrying about races. -This may sound impossible, but is in fact similar to the API -simplification of using a garbage collected language over an explicitly -managed one --- what is not minimal is "just" the internal -implementation of that API. I will explain how it can actually be done -using Automatic Mutual Exclusion, a technique based on Transactional -Memory. I will give preliminary results on a modified version of the -PyPy Python interpreter that show that it can actually work. I will -also explain how the API is used, e.g. in a modified Twisted reactor -that gives multi-core capability to any existing, non-thread-based -Twisted program. + The GIL, or Global Interpreter Lock, is a well-known issue for Python + programmers that want to have a single program using the multiple + cores of today's machines. + + This talk is *not* about writing a GIL-less Python interpreter; + although hard, this has been done before, notably in Jython. The real + issue is that writing each and every multi-threaded Python programs is + hard too. The ``threading`` module offers locks in several variants, + conditions, events, semaphores... But using them correctly without + missing one case is difficult, impossible to seriously test, often + impossible to retrofit into existing programs, and arguably doesn't + scale. (Other solutions like the ``multiprocessing`` module are at + best workarounds, suffering some of the same issues plus their own + ones.) + + Instead, this talk is about an alternate solution: a minimal + thread-less API that lets programs use multiple cores, without + worrying about races. This may sound impossible, but is in fact + similar to the API simplification of using a garbage collected + language over an explicitly managed one --- what is not minimal is + "just" the internal implementation of that API. I will explain how it + can actually be done using Automatic Mutual Exclusion, a technique + based on Transactional Memory. I will give preliminary results on a + modified version of the PyPy Python interpreter that show that it can + actually work. I will also explain how the API is used, e.g. in a + modified Twisted reactor that gives multi-core capability to any + existing, non-thread-based Twisted program. _______________________________________________ pypy-commit mailing list pypy-commit@python.org http://mail.python.org/mailman/listinfo/pypy-commit
