[pypy-svn] r78485 - pypy/extradoc/talk/pycon2011

agaynor at codespeak.net agaynor at codespeak.net
Fri Oct 29 20:59:16 CEST 2010


Author: agaynor
Date: Fri Oct 29 20:59:15 2010
New Revision: 78485

Modified:
   pypy/extradoc/talk/pycon2011/pypy-optimizations.txt
Log:
MOre work on pycon-talk.

Modified: pypy/extradoc/talk/pycon2011/pypy-optimizations.txt
==============================================================================
--- pypy/extradoc/talk/pycon2011/pypy-optimizations.txt	(original)
+++ pypy/extradoc/talk/pycon2011/pypy-optimizations.txt	Fri Oct 29 20:59:15 2010
@@ -1,60 +1,44 @@
 Title: Optimizations in PyPy
 Description:
 
-PyPy is a virtual machine for Python, featuring an advanced just in time compiler, which can deliver exceptional performance.  This talk is going to be a deep dive into what exactly makes Python such a hard language to optimize, how PyPy is organized, and what optimizations our JIT can do for your code.
+PyPy is a virtual machine for Python, featuring an advanced just in time
+compiler, which can deliver exceptional performance.  This talk is going to be
+a deep dive into what exactly makes Python such a hard language to optimize,
+how PyPy is organized, and what optimizations our JIT can do for your code.
 
 Session type: Talk
 Classification: Discuss in depth
 Abstract:
 
-The talk would contain a list of features that are hard to optimize
-in Python, why and how we're fixing it in PyPy. This also might be
-used as a rough guide what features in Python are optimizable right
-now and what are not.
+The talk would contain a list of features that are hard to optimize in Python,
+why and how we're fixing it in PyPy. This also might be used as a rough guide
+what features in Python are optimizable right now and what are not.
 
 The list of mentioned features is not exhaustive, however we will try to
 focus at least on the following:
 
-* Dynamic language - In Python code we have no known types, like a
-  static language.  Even operations like "a + b" can do anything,
-  unless we know more about the code.
-
-* Frame introspection - Frame objects need to be allocated for every
-  function call, and all local variables are stored on the frame, and
-  must be accessible from further down the call stack.
-
-* Object model - All user defined Python objects have a dictionary which
-  stores their attributes, as does every type.  When Python does an
-  attribute lookup this requires 2 dictionary lookups.
+* Dynamic language - In Python code we have no known types, like a static
+  language.  Even operations like "a + b" can do anything, unless we know more
+  about the code.
+
+* Frame introspection - Frame objects need to be allocated for every function
+  call, and all local variables are stored on the frame, and must be accessible
+  from further down the call stack.
+
+* Object model - All user defined Python objects have a dictionary which stores
+  their attributes, as does every type.  When Python does an attribute lookup
+  this requires 2 dictionary lookups.
 
   In PyPy we use an approach similar to one used by v8 with hidden classes
   (except more pypy specific) called shared dictionaries.
 
-* FFI calls - calling C from Python is costly and hard to optimize.
-  In PyPy we decided to go via ctypes, this part will explain how are
-  we going to handle ctypes calls to be fast.
-
-This talk is 3 parts, what's hard to optimize about Python, how PyPy is organized, and what optimizations our JIT can do.
- 
-I. Why Python is hard (8 minutes)
-    A) Dynamic language - No known types, even operations such as "+" can
-    B) Frame introspection.
-    C) Object model.
-    D) CPython
-        1) Interpretation
-        2) Boxing
-II. How PyPy is organized (5 minutes)
-    A) Written in Python
-    B) RPython
-    C) The JIT
-        1) Source transformation on the code
-        2) Orthogonal to the interpreter
-III. Optimizations the JIT does (13 minutes)
-    A) Unboxing
-    B) Attribute lookup
-        1) "Hidden classes"
-    C) Globals/builtin "freezing"
-    D) array module
-    E) The future
-        1) ctypes
-IV. Questions (4 minutes)
+* FFI calls - calling C from Python is costly and hard to optimize. In PyPy we
+  decided to go via ctypes, this part will explain how are we going to handle
+  ctypes calls to be fast.
+
+* `array` module - users of the CPython array module probably know it can save
+  them quiet a bit of memory, however it's also slower than using a list, due
+  to the overhead of boxing and unboxing on every operations. Here we will tie
+  everything together and describe how the ``array`` module is much faster with
+  PyPy's JIT, combining our optimizations to: unbox values, remove the
+  dynamicism within traces, and deliver great performance.



More information about the Pypy-commit mailing list