[pypy-commit] extradoc extradoc: In-progress

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r4954:1eae9d7ddf7f
Date: 2013-03-14 11:24 -0700
http://bitbucket.org/pypy/extradoc/changeset/1eae9d7ddf7f/

Log:	In-progress

diff --git a/talk/pycon2013/pypy_without_gil.txt b/talk/pycon2013/pypy_without_gil.txt
new file mode 100644
--- /dev/null
+++ b/talk/pycon2013/pypy_without_gil.txt
@@ -0,0 +1,140 @@
+====================
+PyPy without the GIL
+====================
+
+Intro
+---------------------------
+
+- PyPy intro
+
+- thanks to contributors for STM
+
+
+
+Demo
+---------------------------
+
+- demo: ~/br/stm-thread-2/64compiled/pypy-c-r61735+-stm
+
+  * run some random multithreaded program
+
+
+- missing in pypy-stm:
+
+  * GC major collection
+  * JIT
+  * some more optimizations possible (= tons of)
+
+
+- __pypy__.thread.atomic
+
+  * with atomic:
+        print "hello", username
+
+  * the illusion of serialization
+
+
+Lower level: STM
+---------------------------
+
+- pypy and not cpython?
+
+
+- STM = Software Transactional Memory
+
+
+- Basic idea: each thread runs in parallel, but everything it does is
+  in a series of "transactions"
+
+
+- A transaction keeps all changes to pre-existing memory "local"
+
+
+- The changes are made visible only when the transaction "commits"
+
+
+- The transaction will "abort" if a conflict is detected, and
+  it will be transparently retried
+
+
+- Non-reversible operations like I/O turn the transaction "inevitable"
+  and stop progress in the other threads
+
+
+- __pypy__.thread.last_abort_info() -> traceback-like information
+
+
+- (GC-supported structure: when we want to modify a pre-existing object,
+  we first copy it into "local" memory, and when we commit, it becomes
+  the newer version of the old pre-existing object; we end up with a
+  chained list of versions, and we have to make sure we always use the
+  latest one.  We rely on GC major collections to free them eventually.)
+
+
+- alternative: HTM...?
+
+
+Higher level: not threads
+---------------------------
+
+
+- based on (and fully compatible with) threads
+
+  * existing multithreaded programs work
+
+
+- but opens up unexpected alternatives
+
+  * we can run multiple threads but at the same time use ``atomic``
+
+  * with the GIL-based idea of ``atomic`` it doesn't make sense:
+    we have multiple threads but they're all using ``atomic``, i.e.
+    only one at a time will ever run...  except no :-)
+
+
+- transaction.py
+
+  * demo
+
+  * illusion of serial execution: can "sanely" reason about algorithms
+
+  * "Conflict tracebacks"
+
+  * Might need to debug them --- but they are performance bugs, not
+    correctness bugs
+
+  * The idea is that we fix only XX% of the bugs and we are done
+
+  * Maybe some new "performance debugger" tools might help us too
+
+
+- TigerQuoll, 1st March: same idea with JavaScript (for servers)
+
+  * various models possible:
+
+    . events dispatchers
+
+    . futures
+
+    . map/reduce, scatter/gather
+
+
+- Event dispatchers
+
+  * twisted, tulip, etc.
+
+  * run the event dispatcher in one thread (e.g. the main thread),
+    and schedule the actual events to run on a different thread from
+    a pool
+
+  * the events are run with ``atomic``, so that they appear to run
+    serially
+
+  * this tweaked event loop should work with just any existing program
+
+
+- Futures
+
+  * e.g. twisted's deferred
+
+  ...