Author: Armin Rigo <[email protected]> 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 + +- _______________________________________________ pypy-commit mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-commit
