[pypy-svn] r27912 - pypy/extradoc/talk/dls2006

arigo at codespeak.net arigo at codespeak.net
Tue May 30 14:20:59 CEST 2006

Author: arigo
Date: Tue May 30 14:20:58 2006
New Revision: 27912

Explained slow.

Modified: pypy/extradoc/talk/dls2006/draft.txt
--- pypy/extradoc/talk/dls2006/draft.txt	(original)
+++ pypy/extradoc/talk/dls2006/draft.txt	Tue May 30 14:20:58 2006
@@ -870,6 +870,10 @@
                      Experimental results
 Our tool-chain is capable of translating the Python interpreter of PyPy,
 written in RPython, producing right now either ANSI C code as described
 before, or LLVM [#]_ assembler which is then natively compiled with LLVM
@@ -957,9 +961,24 @@
     The same as pypy-llvm-c, but using GCC's profile-driven
-XXX explain slow.
+The speed difference with CPython 2.4.3 can be explained at two levels.
+One is that CPython is hand-crafted C code that has been continuously
+optimized for a decade now, whereas the Python interpreter of PyPy first
+seeks flexibility and high abstraction levels.  The other, probably
+dominant, factor is that various indices show that our approach places a
+very high load on the GC and on the memory caches of the machine.  The
+Boehm GC is known to be less efficient than more customized approach;
+kernel-level profiling shows that pypy-c typically spends 30% of its
+time in the Boehm library.  Our current, naively simple mark-and-sweep
+GC is even quite worse.  The interaction with processor caches is also
+hard to predict and account for; in general, we tend to produce
+relatively large amounts of code and prebuilt data.
+Translation times
-The complete translation of the pypy-c variant takes about 39 minutes,
+A complete translation of the pypy-c variant takes about 39 minutes,
 divided as follows:

More information about the Pypy-commit mailing list