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 <[EMAIL PROTECTED]> 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
