Author: Carl Friedrich Bolz <[email protected]>
Branch: extradoc
Changeset: r4845:2f3f32b81966
Date: 2012-10-10 16:37 +0200
http://bitbucket.org/pypy/extradoc/changeset/2f3f32b81966/
Log: a rough structure of the talk
diff --git a/talk/vmil2012/presentation/talk.tex
b/talk/vmil2012/presentation/talk.tex
--- a/talk/vmil2012/presentation/talk.tex
+++ b/talk/vmil2012/presentation/talk.tex
@@ -44,7 +44,7 @@
Heinrich-Heine-Universität Düsseldorf, STUPS Group, Germany
}
-\date{2012 VMIL, XXX}
+\date{2012 VMIL, 21st of October, 2012}
% - Either use conference name or its abbreviation.
% - Not really informative to the audience, more for people (including
% yourself) who are reading the slides online
@@ -80,31 +80,7 @@
\titlepage
\end{frame}
-% XXX todos:
-% note that two fields is a simplification
-% have a diagram for the example trace
-% lifting can never produce new operations
-% have some sort of overview or position indicator for the many graphical
slides, too easy to get lost
-% more details about benchmarks, diagram?
-
-
-% Structuring a talk is a difficult task and the following structure
-% may not be suitable. Here are some rules that apply for this
-% solution:
-
-% - Exactly two or three sections (other than the summary).
-% - At *most* three subsections per section.
-% - Talk about 30s to 2min per frame. So there should be between about
-% 15 and 30 frames, all told.
-
-% - A conference audience is likely to know very little of what you
-% are going to talk about. So *simplify*!
-% - In a 20min talk, getting the main ideas across is hard
-% enough. Leave out details, even if it means being less precise than
-% you think necessary.
-% - If you omit details that are vital to the proof/implementation,
-% just say so once. Everybody will be happy with that.
-
+\section{Introduction}
\begin{frame}
\frametitle{Tracing JITs Compile by Observing an Interpreter}
@@ -119,5 +95,52 @@
\end{itemize}
\end{frame}
+\begin{frame}
+ \frametitle{Guards}
+\end{frame}
+
+% this talk wants to go over a lot of details that are usually glossed over as
+% "easy" when tracing JITs are introduced.
+
+\begin{frame}
+ \frametitle{Bridges}
+\end{frame}
+
+\begin{frame}
+ \frametitle{RPython and PyPy}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Running Example}
+\end{frame}
+
+\section{High-Level}
+
+\begin{frame}
+ \frametitle{Symbolic Frame Capturing}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Symbolic Frame Compression}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Interaction with Optimization}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Emitting Guards}
+\end{frame}
+
+\begin{frame}
+ \frametitle{Patching Guards for Bridges}
+\end{frame}
+
+\section{Evaluation}
+
+%as in paper
+%fancy graphs
+%something about execution speed
+% <demo, if there is time>
\end{document}
_______________________________________________
pypy-commit mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-commit
