Hi, first I'd like to state I'm not part of the Zurich group, so what follows are just my 2 cents. On Mon, Nov 17, 2008 at 14:26, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
Hi Daniel,
Daniel Furrer wrote:
We're looking for: - Hints as to which python compiler would be best to work on. (The official Python compiler package seems very nice to work with actually... [and so does PyPy.])
I guess the problem for "classical" compiler optimizations applied to a compiler producing Python bytecode is that most of them are potentially unsafe. E.g. you cannot do CSE in Python, because any expression can have arbitrary side-effects. Therefore it is very limited which optimizations can be applied at all.
I guess that is because an object can define a custom '+' operator, for instance, right? But aren't those optimizations possible anyway after specialization and inlining? And anyway, who said that CSE should be applied to the Python bytecode? In fact, I think both Java and .NET do it inside the VM. Then, the next point is that you do not have yet a JIT. But still, I think it is possible to specialize bytecode to eliminate dynamic lookups and enable optimizations such as CSE. But the benefit of specialized bytecode can be significant, I guess, only if the interpreter is really fast (either a threaded one, or a code-copying one). Is the PyPy interpreter threaded?
PyPy's translation toolchain works in SSI as an intermediate representation (which is a sub-set of SSA). However, many of the straightforward optimizations (constant-folding, copy-progragation, inlining, a form of escape analysis) have already been implemented. Some things are not done yet, like common subexpression elimination. We didn't bother to implement them yet, because they are not as useful for PyPy since we target C, and most C compilers can do theses things for us.
-- Paolo Giarrusso