[pypy-commit] extradoc extradoc: Tweaks

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r5361:49a0972a00d9
Date: 2014-07-17 15:44 +0200
http://bitbucket.org/pypy/extradoc/changeset/49a0972a00d9/

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
@@ -383,6 +383,18 @@
 <div class="slide" id="part-1-intro-and-current-status">
 <h1>Part 1 - Intro and Current Status</h1>
 </div>
+<div class="slide" id="introduction">
+<h1>Introduction</h1>
+<ul class="simple">
+<li>PyPy-STM: Software Transactional Memory</li>
+<li>On-going research project:<ul>
+<li>by Remi Meier and myself</li>
+<li>helped by crowdfunding, thanks to all donors</li>
+</ul>
+</li>
+<li>Started as a EuroPython 2011 lightning talk</li>
+</ul>
+</div>
 <div class="slide" id="why-is-there-a-gil">
 <h1>Why is there a GIL?</h1>
 <ul class="simple">
@@ -495,10 +507,8 @@
 <ul class="simple">
 <li>application-level locks still needed...</li>
 <li>but <em>can be very coarse:</em><ul>
-<li>the idea is to make sure, internally, that one transaction
-covers the whole time during which the lock was acquired</li>
 <li>even two big transactions can hopefully run in parallel</li>
-<li>even if they both acquire and release the <em>same</em> lock</li>
+<li>even if they both <em>acquire and release the same lock</em></li>
 </ul>
 </li>
 </ul>
@@ -511,6 +521,7 @@
 <div class="slide" id="demo-1">
 <h1>Demo 1</h1>
 <ul class="simple">
+<li>"Twisted apps made parallel out of the box"</li>
 <li>Bottle web server</li>
 </ul>
 </div>
@@ -534,6 +545,7 @@
 <ul class="simple">
 <li>current status:<ul>
 <li>basics work</li>
+<li>best case 25-40% overhead (much better than originally planned)</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
 <li>tons of things to improve</li>
@@ -561,6 +573,10 @@
 <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>
+</ul>
+</li>
 </ul>
 </div>
 <div class="slide" id="part-2-under-the-hood">
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
@@ -17,6 +17,19 @@
 ---------------------------------
 
 
+Introduction
+------------
+
+* PyPy-STM: Software Transactional Memory
+
+* On-going research project:
+
+  - by Remi Meier and myself
+  - helped by crowdfunding, thanks to all donors
+
+* Started as a EuroPython 2011 lightning talk
+
+
 Why is there a GIL?
 -------------------
 
@@ -132,12 +145,9 @@
 
 * but *can be very coarse:*
 
-  - the idea is to make sure, internally, that one transaction
-    covers the whole time during which the lock was acquired
-
   - even two big transactions can hopefully run in parallel
 
-  - even if they both acquire and release the *same* lock
+  - even if they both *acquire and release the same lock*
 
 
 Big Point
@@ -149,6 +159,8 @@
 Demo 1
 ------
 
+* "Twisted apps made parallel out of the box"
+
 * Bottle web server
 
 
@@ -173,6 +185,7 @@
 * current status:
 
   - basics work
+  - best case 25-40% overhead (much better than originally planned)
   - tons of things to improve
   - tons of things to improve
   - tons of things to improve
@@ -201,6 +214,9 @@
 
   - 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
 
 
 Part 2 - Under The Hood