[pypy-commit] extradoc extradoc: STM talk abstract, first version

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r5147:d1c12ea246a5
Date: 2014-02-07 18:10 +0100
http://bitbucket.org/pypy/extradoc/changeset/d1c12ea246a5/

Log:	STM talk abstract, first version

diff --git a/talk/ep2014/stm/abstract.rst b/talk/ep2014/stm/abstract.rst
new file mode 100644
--- /dev/null
+++ b/talk/ep2014/stm/abstract.rst
@@ -0,0 +1,41 @@
+Using All These Cores: Transactional Memory in PyPy
+===================================================
+
+Abstract
+--------
+
+PyPy, the Python implementation written in Python, experimentally
+supports Transactional Memory (TM). The strength of TM is to enable a
+novel use of multithreading, inheritently safe, and not limited to
+special use cases like other approaches. This talk will focus on how it
+works under the hood.
+
+
+Description
+-----------
+
+PyPy is a fast alternative Python implementation.  Software
+Transactional Memory (STM) is a current academic research topic.  Put
+the two together --brew for a couple of years-- and we get a version of
+PyPy that runs on multiple cores, without the infamous Global
+Interpreter Lock (GIL).
+
+The current research is based on a recent new insight that promises to
+give really good performance.  The speed of STM is generally measured by
+two factors: the ability to scale with the number of CPUs, and the
+amount of overhead when compared with other approach in a single CPU (in
+this case, with the regular PyPy with the GIL).  Scaling is not really a
+problem here, but single-CPU performance is --- or used to be.  This new
+approach gives a single-threaded overhead that should be very low ---
+maybe 20%, which would definitely be news for STM systems.  Right now
+(February 2014) we are still implementing it, so we cannot give final
+numbers yet, but early results on a small interpreter for a custom
+language are around 15%.  This might be a deal-changer for STM.
+
+In the talk, I will describe our progress, hopefully along with real
+numbers and demos.  I will then dive under the hood of PyPy to give an
+idea about how it works.  I will conclude with a picture of how the
+future of multi-threaded programming might looks like, for high-level
+languages like Python.  I will also mention CPython: how hard (or not)
+it would be to change the CPython source code to use the same approach.
+