[pypy-commit] extradoc extradoc: Update as a two-parts talk.
arigo
noreply at buildbot.pypy.org
Tue Mar 20 18:40:44 CET 2012
Author: Armin Rigo <arigo at 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.
More information about the pypy-commit
mailing list