[pypy-svn] r34371 - pypy/dist/pypy/doc
mwh at codespeak.net
mwh at codespeak.net
Wed Nov 8 15:07:06 CET 2006
Date: Wed Nov 8 15:07:05 2006
New Revision: 34371
language review + substantial rewriting of the "wp6ish" item.
--- 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
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
+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
-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
+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
-because it does not try to support all pypy (where it might be run than?),
-but rather to compile RPython programs into browser-stuff.
-file. Some project ideas might be:
+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
+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
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
+We already have a somewhat usable `Prolog interpreter`_ and the beginnings of a
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
-.. _`transparent proxy`: proxy.html
\ No newline at end of file
+.. _`transparent proxy`: proxy.html
More information about the Pypy-commit