[pypy-commit] extradoc extradoc: some progress and slidification

[fijal]

Author: Maciej Fijalkowski <fijall at gmail.com>
Branch: extradoc
Changeset: r4958:643f8e36f6a8
Date: 2013-03-15 09:54 -0700
http://bitbucket.org/pypy/extradoc/changeset/643f8e36f6a8/

Log:	some progress and slidification

diff --git a/talk/pycon2013/pypy_without_gil/talk.rst b/talk/pycon2013/pypy_without_gil/talk.rst
--- a/talk/pycon2013/pypy_without_gil/talk.rst
+++ b/talk/pycon2013/pypy_without_gil/talk.rst
@@ -120,64 +120,53 @@
 
 * tons of optimizations possible
 
+How do I use it?
+----------------
 
+* just like with the GIL
 
+* ``__pypy__.thread.atomic``
 
-- __pypy__.thread.atomic
+::
+    with atomic:
+         print "hello", username
 
-  * with atomic:
-        print "hello", username
+* the illusion of serialization
 
-  * the illusion of serialization
+STM - low level
+---------------
 
+* STM = Software Transactional Memory
 
-Lower level: STM
----------------------------
-
-- pypy and not cpython?
-
-
-- STM = Software Transactional Memory
-
-
-- Basic idea: each thread runs in parallel, but everything it does is
+* 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"
 
-- A transaction keeps all changes to pre-existing memory "local"
 
+* The changes are made visible only when the transaction "commits"
 
-- The changes are made visible only when the transaction "commits"
+STM - low level (2)
+-------------------
 
-
-- The transaction will "abort" if a conflict is detected, and
+* 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"
+* 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
+* __pypy__.thread.last_abort_info() -> traceback-like information
 
+Alternative - HTM
+-----------------
 
-- (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...?
-
+XXX
 
 Higher level: not threads
 ---------------------------
 
-
-- xxx memory usage good
-
-
 - based on (and fully compatible with) threads
 
   * existing multithreaded programs work
@@ -192,6 +181,13 @@
     only one at a time will ever run...  except no :-)
 
 
+
+
+- xxx memory usage good
+
+
+
+
 - transaction.py
 
   * demo
@@ -219,15 +215,32 @@
     . map/reduce, scatter/gather
 
 
-- Event dispatchers
+Event dispatchers
+-----------------
 
-  * twisted, tulip, etc.
+* 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
+* 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
+* the events are run with ``atomic``, so that they appear to run
+  serially
 
-  * does not rely on any change to the user program
+* does not rely on any change to the user program
+
+Donate!
+-------
+
+* STM is primarily funded by donations
+
+* We got quite far with $22k USD
+
+* Thanks to the PSF and all others!
+
+* We need your help too
+
+Q&A
+---
+
+* http://pypy.org