[pypy-commit] extradoc extradoc: merge

fijal noreply at buildbot.pypy.org
Wed Feb 29 21:56:23 CET 2012

Author: Maciej Fijalkowski <fijall at gmail.com>
Branch: extradoc
Changeset: r4109:e8ce2e0db76c
Date: 2012-02-29 12:56 -0800

Log:	merge

diff --git a/planning/stm.txt b/planning/stm.txt
--- a/planning/stm.txt
+++ b/planning/stm.txt
@@ -75,8 +75,8 @@
 use 4-5 bits, where in addition we use some "thread hash" value if there
 is only one copy.
-<< NOW: think of a minimal GC model with these properties.  We probably
-need GC_GLOBAL, a single bit of GC_WAS_COPIED, and the version number. >>
+<< NOW: implemented a minimal GC model with these properties.  We have
+GC_GLOBAL, a single bit of GC_WAS_COPIED, and the version number. >>
@@ -102,9 +102,8 @@
   depending on cases).  And if the read is accepted then we need to
   remember in a local list that we've read that object.
-<< NOW: implement the thread's local dictionary in C, as say a search
-tree.  Should be easy enough if we don't try to be as efficient as
-possible.  The rest of the logic here is straightforward. >>
+<< NOW: the thread's local dictionary is in C, as a search tree.
+The rest of the logic here is straightforward. >>
@@ -124,7 +123,7 @@
 consistent copy (i.e. nobody changed the object in the middle of us
 reading it).  If it is too recent, then we might have to abort.
-<< NOW: straightforward >>
+<< NOW: done, straightforward >>
 TODO: how do we handle MemoryErrors when making a local copy??
 Maybe force the transaction to abort, and then re-raise MemoryError
@@ -147,8 +146,7 @@
 We need to check that each of these global objects' versions have not
 been modified in the meantime.
-<< NOW: should be easy, but with unclear interactions between the C
-code and the GC. >>
+<< NOW: done, kind of easy >>
 Annotator support
@@ -167,7 +165,10 @@
 of a localobj are themselves localobjs.  This would be useful for
 'PyFrame.fastlocals_w': it should also be known to always be a localobj.
-<< do later >>
+<< NOW: done in the basic form by translator/stm/transform.py.
+Runs late (just before C databasing).  Should work well enough to
+remove the maximum number of write barriers, but still missing
+PyFrame.fastlocals_w. >>
 Local collections
@@ -243,7 +244,9 @@
 << at first the global area keeps growing unboundedly.  The next step
 will be to add the LIL but run the global collection by keeping all
-other threads blocked. >>
+other threads blocked.  NOW: think about, at least, doing "minor
+collections" on the global area *before* we even start running
+transactions. >>
 When not running transactively
@@ -267,19 +270,10 @@
 is called, we can try to do such a collection, but what about the pinned
-<< NOW: let this mode be rather slow.  Two solutions are considered:
-    1. we would have only global objects, and have the stm_write barrier
-    of 'obj' return 'obj'.  Do only global collections (once we have
-    them; at first, don't collect at all).  Allocation would allocate
-    immediately a global object, without being able to benefit from
-    bump-pointer allocation.
-    2. allocate in a nursery, never collected for now; but just do an
-    end-of-transaction collection when transaction.run() is first
-    called.
+<< NOW: the global area is just the "nursery" for the main thread.
+stm_writebarrier of 'obj' return 'obj' in the main thread.  All
+allocations get us directly a global object, but allocated from
+the "nursery" of the main thread, with bump-pointer allocation. >>
 Pointer equality
@@ -296,8 +290,11 @@
 dictionary if they map to each other.  And we need to take care of the
 cases of NULL pointers.
-<< NOW: straightforward, if we're careful not to forget cases >>
+<< NOW: done, without needing the local dictionary:
+stm_normalize_global(obj) returns globalobj if obj is a local,
+WAS_COPIED object.  Then a pointer comparison 'x == y' becomes
+stm_normalize_global(x) == stm_normalize_global(y).  Moreover
+the call to stm_normalize_global() can be omitted for constants. >>
diff --git a/talk/pycon2012/tutorial/slides.rst b/talk/pycon2012/tutorial/slides.rst
--- a/talk/pycon2012/tutorial/slides.rst
+++ b/talk/pycon2012/tutorial/slides.rst
@@ -1,3 +1,44 @@
+First rule of optimization?
+If it's not correct, it doesn't matter.
+Second rule of optimization?
+If it's not faster, you're wasting ime.
+Third rule of optimization?
+Measure twice, cut once.
+(C)Python performance tricks
+* ``map()`` instead of list comprehensions
+* ``def f(int=int):``, make globals local
+* ``append = my_list.append``, grab bound methods outside loop
+* Avoiding function calls
+Forget these
+* PyPy has totally different performance characterists
+* Which we're going to learn about now
 Why PyPy?
@@ -41,7 +82,7 @@
 * moving computations to C, example::
-   map(operator.... ) # XXX some obscure example
+   map(operator.attrgetter("a"), my_list)
 PyPy's sweetpot

More information about the pypy-commit mailing list