[pypy-commit] extradoc extradoc: Tweaks

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r5370:3190704f9cd2
Date: 2014-07-22 18:01 +0200
http://bitbucket.org/pypy/extradoc/changeset/3190704f9cd2/

Log:	Tweaks

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
@@ -488,7 +488,7 @@
 <div class="slide" id="transactional-memory">
 <h1>Transactional Memory</h1>
 <ul class="simple">
-<li>like GIL, but instead of locking, each thread runs optimistically</li>
+<li>like GIL, but instead of blocking, each thread runs optimistically</li>
 <li>"easy" to implement:<ul>
 <li>GIL acquire -> transaction start</li>
 <li>GIL release -> transaction commit</li>
@@ -507,7 +507,7 @@
 <ul class="simple">
 <li>application-level locks still needed...</li>
 <li>but <em>can be very coarse:</em><ul>
-<li>even two big transactions can hopefully run in parallel</li>
+<li>even two big transactions can optimistically run in parallel</li>
 <li>even if they both <em>acquire and release the same lock</em></li>
 </ul>
 </li>
@@ -546,6 +546,7 @@
 <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</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
@@ -563,18 +564,38 @@
 <li>counting primes</li>
 </ul>
 </div>
+<div class="slide" id="benefits">
+<h1>Benefits</h1>
+<ul class="simple">
+<li>Keep locks coarse-grained</li>
+<li>Potential to enable parallelism:<ul>
+<li>in CPU-bound multithreaded programs</li>
+<li>or as a replacement of <tt class="docutils literal">multiprocessing</tt></li>
+<li>but also in existing applications not written for that</li>
+<li>as long as they do multiple things that are "often independent"</li>
+</ul>
+</li>
+</ul>
+</div>
+<div class="slide" id="issues">
+<h1>Issues</h1>
+<ul class="simple">
+<li>Performance hit: 25-40% everywhere (may be ok)</li>
+<li>Keep locks coarse-grained:<ul>
+<li>but in case of systematic conflicts, performance is bad again</li>
+<li>need to track and fix them</li>
+<li>need tool support (debugger/profiler)</li>
+</ul>
+</li>
+</ul>
+</div>
 <div class="slide" id="summary">
 <h1>Summary</h1>
 <ul class="simple">
 <li>Transactional Memory is still too researchy for production</li>
-<li>Potential to enable parallelism:<ul>
-<li>as a replacement of <tt class="docutils literal">multiprocessing</tt></li>
-<li>but also in existing applications not written for that</li>
-<li>as long as they do multiple things that are "often independent"</li>
-</ul>
-</li>
-<li>Keep locks coarse-grained:<ul>
-<li>need to track and fix issues in case of systematic conflicts</li>
+<li>But it has the potential to enable "easier parallelism"</li>
+<li>Still alpha but slowly getting there!<ul>
+<li>see <a class="reference external" href="http://morepypy.blogspot.com/">http://morepypy.blogspot.com/</a></li>
 </ul>
 </li>
 </ul>
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
@@ -122,7 +122,7 @@
 Transactional Memory
 --------------------
 
-* like GIL, but instead of locking, each thread runs optimistically
+* like GIL, but instead of blocking, each thread runs optimistically
 
 * "easy" to implement:
 
@@ -145,7 +145,7 @@
 
 * but *can be very coarse:*
 
-  - even two big transactions can hopefully run in parallel
+  - even two big transactions can optimistically run in parallel
 
   - even if they both *acquire and release the same lock*
 
@@ -186,6 +186,7 @@
 
   - basics work
   - best case 25-40% overhead (much better than originally planned)
+  - parallelizing user locks not done yet
   - tons of things to improve
   - tons of things to improve
   - tons of things to improve
@@ -201,22 +202,46 @@
 * counting primes
 
 
+Benefits
+--------
+
+* Keep locks coarse-grained
+
+* Potential to enable parallelism:
+
+  - in CPU-bound multithreaded programs
+
+  - or as a replacement of ``multiprocessing``
+
+  - but also in existing applications not written for that
+
+  - as long as they do multiple things that are "often independent"
+
+
+Issues
+------
+
+* Performance hit: 25-40% everywhere (may be ok)
+
+* Keep locks coarse-grained:
+
+  - but in case of systematic conflicts, performance is bad again
+
+  - need to track and fix them
+
+  - need tool support (debugger/profiler)
+
+
 Summary
 -------
 
 * Transactional Memory is still too researchy for production
 
-* Potential to enable parallelism:
+* But it has the potential to enable "easier parallelism"
 
-  - as a replacement of ``multiprocessing``
+* Still alpha but slowly getting there!
 
-  - but also in existing applications not written for that
-
-  - as long as they do multiple things that are "often independent"
-
-* Keep locks coarse-grained:
-    
-  - need to track and fix issues in case of systematic conflicts
+  - see http://morepypy.blogspot.com/
 
 
 Part 2 - Under The Hood