[pypy-svn] r34371 - pypy/dist/pypy/doc

mwh at codespeak.net mwh at codespeak.net
Wed Nov 8 15:07:06 CET 2006


Author: mwh
Date: Wed Nov  8 15:07:05 2006
New Revision: 34371

Modified:
   pypy/dist/pypy/doc/project-ideas.txt
Log:
language review + substantial rewriting of the "wp6ish" item.


Modified: pypy/dist/pypy/doc/project-ideas.txt
==============================================================================
--- pypy/dist/pypy/doc/project-ideas.txt	(original)
+++ pypy/dist/pypy/doc/project-ideas.txt	Wed Nov  8 15:07:05 2006
@@ -1,9 +1,12 @@
-Independent project ideas in PyPy
-=================================
+Independent project ideas relating to PyPy
+==========================================
 
 PyPy allows experimentation in many directions -- indeed facilitating
-experimentation in language implementation was one of the main motivations for
-the project.  This page is meant to collect some ideas of things to try.
+experimentation in language implementation was one of the main
+motivations for the project.  This page is meant to collect some ideas
+of experiments that the core developers have not had time to perform
+yet and also do not require too much in depth knowledge to get started
+with.
 
 If you are a student, maybe you will be inspired to make a proposal for our
 `Summer of PyPy`_ campaign: you will have an experienced PyPy developer as a
@@ -20,15 +23,16 @@
 Experiment with optimizations
 -----------------------------
 
-A research project: experiment with optimizations in PyPy, e.g. by trying
-various **data structures** for dicts or other built-in objects, by switching
-between data structures at run-time, comparing results for different
-applications, etc.  This should produce experimental results (mostly timings,
-memory usage trade-offs) as much as code.  (The point of PyPy is that we can
-do this without making the interpreted applications aware of the optimization
-at all.)
+Although PyPy's Python interpreter is very compatible with CPython, it is not
+yet as fast.  There are several approaches to making it faster, including the
+on-going Just-In-Time compilation efforts and improving the compilation tool
+chain, but probably the most suited to being divided into reasonably sized
+chunks is to play with alternate implementations of key data structures or
+algorithms used by the interpreter.  PyPy's structure is designed to make this
+straightforward, so it is easy to provide a different implementation of, say,
+dictionaries or lists without disturbing any other code.
 
-For example, we've got working implementations of things like:
+As examples, we've got working implementations of things like:
 
 * lazy string slices (slicing a string gives an object that references a part
   of the original string).
@@ -38,52 +42,68 @@
 
 * dictionaries specialized for string-only keys.
 
-Other interesting ideas might be:
+* dictionaries which use a different strategy when very small.
+
+Things we've thought about but not yet implemented include:
 
 * lists which are specialised for int-only values (for saving memory).
 
+* some form of caching the lookups of builtin or even global names (mostly
+  likely by special forms of dictionaries that can invalidate the caches when
+  they are written to).
+
+Experiments of this kind are really experiments in the sense that we do not know
+whether they will work well or not and the only way to find out is to try.  A
+project of this nature should provide benchmark results (both timing and memory
+usage) as much as code.
+
 Start or improve a back-end
 ---------------------------
 
-PyPy has complete, or nearly so, back-ends for C, LLVM and CLI/.NET and
-partial backends for JavaScript, Common Lisp, Squeak and the JVM.  It would 
-be an interesting project to improve either of these partial backends, 
-or start one for another platform (objective C comes to mind).
+PyPy has complete, or nearly so, back-ends for C, LLVM and CLI/.NET and partial
+backends for JavaScript, Common Lisp, Squeak and the JVM.  It would be an
+interesting project to improve either of these partial backends, or start one
+for another platform (Objective C comes to mind as one that should not be too
+terribly hard).
 
 Improve JavaScript backend
 --------------------------
 
-A JavaScript backend is somehow different from other pypy's backends 
-because it does not try to support all pypy (where it might be run than?),
-but rather to compile RPython programs into browser-stuff. 
-Some documents are in a `JavaScript whatis`_ file and a `JavaScript using`_ 
-file. Some project ideas might be:
+The JavaScript backend is somehow different from other pypy's backends because
+it does not try to support all of PyPy (where it might be run then?), but rather
+to compile RPython programs into code that runs in a browser.  Some documents
+are in `what is PyPy.js`_ file and `using the JavaScript backend`_. Some project
+ideas might be:
 
-* Write some examples to show different possibilities of using them
+* Write some examples to show different possibilities of using the backend.
 
-* Improve facilities of testing RPython code on top of CPython, mostly
-  by improving existing DOM interface.
+* Improve the facilities for testing RPython intended to be translated to
+  JavaScript on top of CPython, mostly by improving existing DOM interface.
 
 Improve one of the JIT back-ends
 --------------------------------
 
 PyPy's Just-In-Time compiler relies on two assembler backends for actual code
-generation: One for PowerPC and one for i386. Those two backends so far are
-mostly working, but nearly no effort was made to make them produce good
-assembler. This is an area where quite some improvements could be made.
-Another idea in a similar vein would be to use LLVM to re-compile functions
-that are particularly often used (LLVM cannot be used for *all* code
+generation, one for PowerPC and the other for i386. Those two backends so far
+are mostly working, but nearly no effort has been made to make them produce
+efficient code. This is an area where significant improvements could be made,
+hopefully without having to understand the full intricacies of the JIT.
+
+Another idea in a similar vein would be to use LLVM to re-compile functions that
+are executed particularly frequently (LLVM cannot be used for *all* code
 generation, since it can only work on function at a time).
 
 Write a new front end
 ---------------------
 
 Write an interpreter for **another dynamic language** in the PyPy framework.
-For example, a Scheme interpreter would be suitable.  Ruby too (though
-the latter is probably more than two months of work), or Lua, or ...
+For example, a Scheme interpreter would be suitable (and it would even be
+interesting from a semi-academic point of view to see if ``call/cc`` can be
+implemented on top of the primitives the stackless transform provides).  Ruby
+too (though the latter is probably more than two months of work), or Lua, or ...
 
-We have a somewhat useable `Prolog interpreter`_ and the beginnings of a
-`JavaScript interpreter`_
+We already have a somewhat usable `Prolog interpreter`_ and the beginnings of a
+`JavaScript interpreter`_.
 
 Investigate restricted execution models
 ---------------------------------------
@@ -96,7 +116,7 @@
 about safely executing limited snippets of untrusted RPython code (see
 http://codespeak.net/pipermail/pypy-dev/2006q2/003131.html).  More general
 approaches, to execute general but untrusted Python code on top of PyPy,
-require more design.  The object space model of PyPy would easily allow
+require more design.  The object space model of PyPy will easily allow
 objects to be tagged and tracked.  The translation of PyPy would also be a
 good place to insert e.g. systematic checks around all system calls.
 
@@ -174,9 +194,6 @@
 
 ...or whatever else interests you!
 
-Note: currently it is a bit difficult for us to identify nice independent
-sub-tasks in the context of the JIT compiler of PyPy...
-
 Feel free to mention your interest and discuss these ideas on the `pypy-dev
 mailing list`_.  You can also have a look around our documentation_.
 
@@ -197,4 +214,4 @@
 .. _`ZODB's Persistent class`: http://www.zope.org/Documentation/Books/ZDG/current/Persistence.stx
 .. _`JavaScript whatis`: js/whatis.html
 .. _`JavaScript using`: js/using.html
-.. _`transparent proxy`: proxy.html
\ No newline at end of file
+.. _`transparent proxy`: proxy.html



More information about the Pypy-commit mailing list