[pypy-dev] compiler optimizations: collecting ideas
p.giarrusso at gmail.com
Mon Nov 17 14:51:15 CET 2008
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 at 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
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.
More information about the Pypy-dev