[pypy-svn] r60577 - pypy/extradoc/talk/ecoop2009

cfbolz at codespeak.net cfbolz at codespeak.net
Thu Dec 18 15:50:06 CET 2008


Author: cfbolz
Date: Thu Dec 18 15:50:05 2008
New Revision: 60577

Added:
   pypy/extradoc/talk/ecoop2009/tlc-folded.py   (contents, props changed)
   pypy/extradoc/talk/ecoop2009/tlc-simplified.py   (contents, props changed)
Modified:
   pypy/extradoc/talk/ecoop2009/jitgen.tex
Log:
add a tlc-based example for partial evaluation.


Modified: pypy/extradoc/talk/ecoop2009/jitgen.tex
==============================================================================
--- pypy/extradoc/talk/ecoop2009/jitgen.tex	(original)
+++ pypy/extradoc/talk/ecoop2009/jitgen.tex	Thu Dec 18 15:50:05 2008
@@ -56,36 +56,50 @@
 depend only on the $s_1, ..., s_m$ and to remove parts of $P$ that cannot be
 reached given the concrete values.
 
+\begin{figure}[h]
+\label{fig:tlc-main}
+\begin{center}
+\input{tlc-simplified.py}
+\caption{The main loop of the TLC interpreter}
+\end{center}
+\end{figure}
+
+Let us look at an example. Figure \ref{fig:tlc-main} shows parts of the
+main-loop of the TLC interpreter (in slightly simplified form). The static
+arguments of this functions would typically be the \lstinline{code} argument
+(containing the bytecode as a string), the \lstinline{pc} argument (containing
+the initial program counter) and the \lstinline{pool} argument (containing the
+constant pool). The \lstinline{args} argument is dynamic since it contains the
+user-input of the interpreted function. Since the \lstinline{while} loop and the
+contained conditions depend only on static arguments it will typically be
+unrolled by a partial evaluator.
+
+When the function is partially evaluated with respect to the TLC example
+function shown in Figure XXX (which computes the absolute value of a number),
+the residual code would look like in Figure \ref{fig:tlc-folded}. This version
+is already a great improvement over pure interpretation, all the bytecode
+dispatch overhead has been removed. However, the function as shown is still
+rather inefficient, due to lots of superfluous stack handling and also due to
+some indirect calls for implementing comparison (\lstinline{lt}) and
+subtraction (\lstinline{sub}).
+
+\begin{figure}[h]
+\label{fig:tlc-folded}
+\begin{center}
+\input{tlc-folded.py}
+\caption{The residual code of the TLC main loop with respect to the
+\lstinline{abs} function }
+\end{center}
+\end{figure}
+
+This shows a common shortcoming of partial evaluation when applied to a dynamic
+language: The partial evaluator (just like an ahead-of-time compiler) cannot
+make assumptions about the types of objects, which leads to poor results.
+Effective dynamic compilation requires feedback of runtime information into
+compile-time. This is no different for partial evaluation.
 
-\cfbolz{I would propose to use either TLC as an example here, or something that
-looks at least like an interpreter loop}
-
-Example::
-\begin{lstlisting}[language=Python]
-  def f(x, y):    
-    x2 = x * x    
-    y2 = y * y    
-    return x2 + y2
-
-**case x=3** ::
-
-  def f_3(y):    
-    y2 = y * y   
-    return 9 + y2
-
-**case x=10** ::
-
-  def f_10(y):    
-    y2 = y * y   
-    return 100 + y2
-\end{lstlisting}
-
-A shortcoming of PE is that in many cases not much can be really assumed
-constant at compile-time, and this leads to poor results.  Effective dynamic
-compilation requires feedback of runtime information into compile-time; for a
-dynamic language, types are a primary example.
-
-Partial evaluation (PE) comes in two flavors:
+Partial evaluation (PE) comes in two flavors: \cfbolz{if we have space problems
+we should kill the bits about online and offline PE}
 
 \begin{itemize}
 \item \emph{On-line} partial evaluation: a compiler-like algorithm takes the

Added: pypy/extradoc/talk/ecoop2009/tlc-folded.py
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/ecoop2009/tlc-folded.py	Thu Dec 18 15:50:05 2008
@@ -0,0 +1,18 @@
+\begin{lstlisting}[language=Python]
+def interp_eval_abs(args):
+    stack = []
+    stack.append(args[0])
+    stack.append(IntObj(0))
+    a, b = stack.pop(), stack.pop()
+    stack.append(IntObj(b.lt(a)))
+    cond = stack.pop()
+    if cond.istrue():
+        stack.append(args[0])
+        return stack[-1]
+    else:
+        stack.append(IntObj(0))
+        stack.append(args[0])
+        a, b = stack.pop(), stack.pop()
+        stack.append(b.sub(a))
+        return stack[-1]
+\end{lstlisting}

Added: pypy/extradoc/talk/ecoop2009/tlc-simplified.py
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/ecoop2009/tlc-simplified.py	Thu Dec 18 15:50:05 2008
@@ -0,0 +1,29 @@
+\begin{lstlisting}[language=Python]
+def interp_eval(code, pc, args, pool):
+    code_len = len(code)
+    stack = []
+    while pc < code_len:
+        opcode = ord(code[pc])
+        pc += 1
+
+        if opcode == PUSH:
+            stack.append(IntObj(char2int(code[pc])))
+            pc += 1
+        elif opcode == PUSHARG:
+            stack.append(args[0])
+        elif opcode == SUB:
+            a, b = stack.pop(), stack.pop()
+            stack.append(b.sub(a))
+        elif opcode == LT:
+            a, b = stack.pop(), stack.pop()
+            stack.append(IntObj(b.lt(a)))
+        elif opcode == BR_COND:
+            cond = stack.pop()
+            if cond.istrue():
+                pc += char2int(code[pc])
+            pc += 1
+        elif opcode == RETURN:
+            break
+        ...
+    return stack[-1]
+\end{lstlisting}



More information about the Pypy-commit mailing list