[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
http://bitbucket.org/pypy/extradoc/changeset/e8ce2e0db76c/
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. >>
stm_read
@@ -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. >>
stm_write
@@ -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
objects?
-<< 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?
+===========================
+
+|pause|
+
+If it's not correct, it doesn't matter.
+
+Second rule of optimization?
+============================
+
+|pause|
+
+If it's not faster, you're wasting ime.
+
+Third rule of optimization?
+===========================
+
+|pause|
+
+Measure twice, cut once.
+
+(C)Python performance tricks
+============================
+
+|pause|
+
+* ``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