[pypy-commit] extradoc extradoc: merged upstream
noreply at buildbot.pypy.org
Wed Feb 22 02:26:14 CET 2012
Author: Alex Gaynor <alex.gaynor at gmail.com>
Date: 2012-02-21 20:26 -0500
Log: merged upstream
diff --git a/planning/separate-compilation.txt b/planning/separate-compilation.txt
new file mode 100644
@@ -0,0 +1,81 @@
+Translation extension modules written in RPython.
+The best form is probably the MixedModule.
+The main executable (bin/pypy-c or libpypy-c.dll) exports RPython
+functions; this "first translation" also produces a pickled object
+that describe these functions: signatures, exception info, etc.
+It will probably be necessary to list all exported functions and methods,
+or mark them with some @exported decorator.
+The translation of an extension module (the "second translation") will
+reuse the information from the pickled object; the content of the
+MixedModule is annotated as usual, except that functions exported by
+the main executable are now external calls.
+The extension module simply has to export a single function
+"init_module()", which at runtime uses space operations to create and
+install a module.
+* First, a framework to test and measure progress; builds two
+ shared libraries (.so or .dll):
+ - the first one is the "core module", which exports functions
+ - that can be called from the second module, which exports a single
+ entry point that we call call with ctypes.
+* Find a way to mark functions as "exported". We need to either
+ provide a signature, or be sure that the functions is somehow
+ annotated (because it is already used by the core interpreter)
+* Pass structures (as opaque pointers). At this step, only the core
+ module has access to the fields.
+* Implement access to struct fields: an idea is to use a Controller
+ object, and redirect attribute access to the ClassRepr computed by
+ the first translation.
+* Implement method calls, again with the help of the Controller which
+ can replace calls to bound methods with calls to exported functions.
+* Share the ExceptionTransformer between the modules: a RPython
+ exception raised on one side can be caught by the other side.
+* Support subclassing. Two issues here:
+ - isinstance() is translated into a range check, but these minid and
+ maxid work because all classes are known at translation time.
+ Subclasses defined in the second module must use the same minid
+ and maxid as their parent; isinstance(X, SecondModuleClass) should
+ use an additional field. Be sure to not confuse classes
+ separately created in two extension modules.
+ - virtual methods, that override methods defined in the first
+* specialize.memo() needs to know all possible values of a
+ PreBuildConstant to compute the results during translation and build
+ some kind of lookup table. The most obvious case is the function
+ space.gettypeobject(typedef). Fortunately a PBC defined in a module
+ can only be used from the same module, so the list of prebuilt
+ results is probably local to the same module and this is not really
+ an issue.
+* Integration with GC. The GC functions should be exported from the
+ first module, and we need a way to register the static roots of the
+ second module.
+* Integration with the JIT.
diff --git a/talk/sea2012/talk.rst b/talk/sea2012/talk.rst
@@ -8,9 +8,9 @@
* What is PyPy and why?
-* Numeric landscape in python
+* Numeric landscape in Python
-* What we achieved in PyPy?
+* What we achieved in PyPy
* Where we're going?
@@ -21,7 +21,7 @@
* A framework for writing efficient dynamic language implementations
-* An open source project with a lot of volunteer effort, released under the BSD license
+* An open source project with a lot of volunteer effort, released under the MIT license
* I'll talk today about the first part (mostly)
@@ -36,28 +36,28 @@
* XXX some benchmarks
-Why would you care?
+Why should you care?
* *If I write this stuff in C/fortran/assembler it'll be faster anyway*
* maybe, but ...
-Why would you care (2)
+Why should you care? (2)
* Experimentation is important
* Implementing something faster, in **human time**, leaves more time for optimizations and improvements
-* For novel algorithms, being clearly expressed in code makes them easier to evaluate (Python is cleaner than C often)
+* For novel algorithms, clearer implementation makes them easier to evaluate (Python often is cleaner than C)
* Sometimes makes it **possible** in the first place
-Why would you care even more
+Why would you care even more?
* Growing community
@@ -65,8 +65,8 @@
* There are many smart people out there addressing hard problems
-Example why would you care
+Example of why would you care
* You spend a year writing optimized algorithms for a GPU
@@ -78,11 +78,11 @@
* Alternative - **express** your algorithms
-* Leave low-level details for people who have nothing better to do
+* Leave low-level details to people who have nothing better to do
-* .. like me (I don't know enough physics to do the other part)
+* ... like me (I don't know enough Physics to do the other part)
Numerics in Python
@@ -197,7 +197,7 @@
-* However, leave knobs and buttons for advanced users
+* However, retain knobs and buttons for advanced users
* Don't get penalized too much for not using them
More information about the pypy-commit