[pypy-commit] extradoc extradoc: in-(slow)-progress

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r5355:f0be65f30f5a
Date: 2014-07-15 22:42 +0200
http://bitbucket.org/pypy/extradoc/changeset/f0be65f30f5a/

Log:	in-(slow)-progress

diff --git a/talk/ep2014/stm/talk.rst b/talk/ep2014/stm/talk.rst
--- a/talk/ep2014/stm/talk.rst
+++ b/talk/ep2014/stm/talk.rst
@@ -7,7 +7,51 @@
 Part 1 - Intro and Current Status
 ===========================================
 
-xxx
+- stm/demo/
+
+- stm/bottle/
+
+- transaction module; multiprocessing-like Pool(); etc.
+
+- a large demo of some well-known program where
+  it solves everything?... there is no such thing
+  because the large program's author have already
+  solved it
+
+- compare with garbage collection in C:
+
+  - usually you do it with malloc()/free()
+
+  - sometimes you need more control, and e.g. you add
+    some reference counts
+
+  - sometimes you use more specialized versions for
+    performance, e.g. allocate in a pool and throw it
+    completely away at the end of some phase
+
+  - Boehm GC, a GC for C: what kind of demo can you
+    present for it?  You take a C program, remove all
+    free(), relink malloc() to Boehm, and it works
+    more slowly...
+
+  - nevertheless, GCC did exactly that.  Why?
+
+- so, the GIL: we already have different workarounds for
+  different kinds of problems (use "multiprocessing"; or
+  start N processes and have them communicate in one
+  way or another)
+
+- this talk is about the GIL's equivalent of the Boehm GC
+  for C: simplify your life for some problems, with a
+  reasonable performance cost
+
+- the problems are:
+
+  - anything where the GIL is a blocker, obviously
+
+  - but also any program with "often-parallelizable"
+    sections of code
+
 
 
 ===========================================
@@ -33,7 +77,8 @@
 - reads are more common than writes: optimize read barriers
 
 - pypy-stm: write a thread-local flag "this object has been read",
-  show code for read barrier and fast-path of write barrier
+  show code for read barrier and fast-path of write barrier;
+  note about using the C library for CPython too
 
 - reads are not synchronized at all between CPUs, but it's wrong
   to read data written by other in-progress transactions;
@@ -55,8 +100,10 @@
 - picture with nursery -- the GC can use the same write barrier
 
 
+
 ===========================================
 Part 3 - Multithreading Revisited
 ===========================================
 
-xxx
+
+-