[pypy-commit] extradoc extradoc: tweaks

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r5373:8fe97fa6f212
Date: 2014-07-23 10:51 +0200
http://bitbucket.org/pypy/extradoc/changeset/8fe97fa6f212/

Log:	tweaks

diff --git a/talk/ep2014/stm/demo/bench-multiprocessing.py b/talk/ep2014/stm/demo/bench-multiprocessing.py
--- a/talk/ep2014/stm/demo/bench-multiprocessing.py
+++ b/talk/ep2014/stm/demo/bench-multiprocessing.py
@@ -8,7 +8,7 @@
             subtotal += 1
     return subtotal
 
-pool = Pool(4)
+pool = Pool(2)
 results = pool.map(process, xrange(0, 5000000, 20000))
 total = sum(results)
 
diff --git a/talk/ep2014/stm/talk.html b/talk/ep2014/stm/talk.html
--- a/talk/ep2014/stm/talk.html
+++ b/talk/ep2014/stm/talk.html
@@ -535,7 +535,6 @@
 <li>but <em>can be very coarse:</em><ul>
 <li>two transactions can optimistically run in parallel</li>
 <li>even if they both <em>acquire and release the same lock</em></li>
-<li>internally, drive the transaction lengths by the locks we acquire</li>
 </ul>
 </li>
 </ul>
@@ -558,19 +557,30 @@
 <li>this is not "everybody should use careful explicit threading
 with all the locking issues"</li>
 <li>instead, PyPy-STM pushes forward:<ul>
-<li>use a thread pool library</li>
+<li>make or use a thread pool library</li>
 <li>coarse locking, inside that library only</li>
 </ul>
 </li>
 </ul>
 </div>
+<div class="slide" id="id4">
+<h1>PyPy-STM Programming Model</h1>
+<ul class="simple">
+<li>e.g.:<ul>
+<li><tt class="docutils literal">multiprocessing</tt>-like thread pool</li>
+<li>Twisted/Tornado/Bottle extension</li>
+<li>Stackless/greenlet/gevent extension</li>
+</ul>
+</li>
+</ul>
+</div>
 <div class="slide" id="pypy-stm-status">
 <h1>PyPy-STM status</h1>
 <ul class="simple">
 <li>current status:<ul>
 <li>basics work</li>
 <li>best case 25-40% overhead (much better than originally planned)</li>
-<li>parallelizing user locks not done yet (see "with atomic")</li>
+<li>app locks not done yet ("with atomic" workaround)</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
@@ -604,7 +614,7 @@
 <li>need tool to support this (debugger/profiler)</li>
 </ul>
 </li>
-<li>Performance hit: 25-40% over a plain PyPy-JIT (may be ok)</li>
+<li>Performance hit: 25-40% slower than a plain PyPy-JIT (may be ok)</li>
 </ul>
 </div>
 <div class="slide" id="summary-pypy-stm">
@@ -678,7 +688,7 @@
 a read flag set in some other thread</li>
 </ul>
 </div>
-<div class="slide" id="id4">
+<div class="slide" id="id5">
 <h1>...</h1>
 </div>
 <div class="slide" id="thank-you">
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
@@ -176,8 +176,6 @@
 
   - even if they both *acquire and release the same lock*
 
-  - internally, drive the transaction lengths by the locks we acquire
-
 
 Long Transactions
 -----------------
@@ -201,11 +199,23 @@
 
 * instead, PyPy-STM pushes forward:
 
-  - use a thread pool library
+  - make or use a thread pool library
 
   - coarse locking, inside that library only
 
 
+PyPy-STM Programming Model
+--------------------------
+
+* e.g.:
+
+  - ``multiprocessing``-like thread pool
+
+  - Twisted/Tornado/Bottle extension
+
+  - Stackless/greenlet/gevent extension
+
+
 PyPy-STM status
 ---------------
 
@@ -213,7 +223,7 @@
 
   - basics work
   - best case 25-40% overhead (much better than originally planned)
-  - parallelizing user locks not done yet (see "with atomic")
+  - app locks not done yet ("with atomic" workaround)
   - tons of things to improve
   - tons of things to improve
   - tons of things to improve
@@ -250,7 +260,7 @@
 
   - need tool to support this (debugger/profiler)
 
-* Performance hit: 25-40% over a plain PyPy-JIT (may be ok)
+* Performance hit: 25-40% slower than a plain PyPy-JIT (may be ok)
 
 
 Summary: PyPy-STM