[pypy-dev] More on optimization

Armin Rigo arigo at tunes.org
Wed Nov 3 15:37:53 CET 2004

Hi Samuele,

On Tue, Nov 02, 2004 at 06:09:57PM +0100, Samuele Pedroni wrote:
> In general I think that likely both 1 and 2 are worth pursuing, because 
> of differences for target languages, characheteristic of produced code.

Makes sense.  We must set priorities, and trying to go as far as possible with
the existing approach certainly looks like a good idea.  This means that we
shouldn't put too many optimization efforts on the current C backend.  I
suggest that the next goal would be to get something that works, even slowly,
and try to keep the Lisp backend up-to-date.  I think that the type
annotations are not used much in the Lisp backend so far, but it should be
easy to generate type declarations.  It might be a good way to get a "fast
enough" translation.

> I see, I just think that maybe we should try to get as far as possible 
> with what we constructed so far, for example even ignoring structure 
> inlining for the first approx. In Java, lisp etc is not that much a 
> relevant problem because for example Java arrays carry a length anyway 
> and are heap allocated.

Indeed, it looks like structure inlining ("option 2") is not really useful for
all target languages.

> One thing with approach 2 is that we need to rewrite a fair chunk of 
> Python semantics themself in the compiler that way.

Yes, though these semantics have to be somewhere anyway; currently they are
distributed among the type inference, the backend itself, and in manually
written support code for the target language (i.e. the C macro file genc.h, or
the snippets of Lisp code included in gencl.py).  Approach 2 would put them in
a central place, making the meta-programming Psyco-ish approach more explicit.

> I'm thinking that  as long as we depend/use on CPython ref counting, 
> ownership issues will crop up, they will likely not mix easely with 
> trying to be clever with structures.

I don't think that reference counting is a major problem.  The way I see
approach 2 so far is that we'd have basically two kinds of annotations for the
low-level graphs, SomeInlinedStructure and SomeHeapStructure.  We'd use the
former as long as possible, i.e. as long as we can track all references to the
structure; and when we no longer can, we mark the structure's creation point
as "too complex" and reflow from there using SomeHeapStructure instead.  Only
the latter would have reference counters and a CPython-compatible layout in

> OTOH I'm sure whether trying to go with full force with 2 is the best 
> thing to get the first protototype interpreter running as an extension 
> in CPython, especially thinking about ref counting.

I agree with you now for the reasons above, even if I think that the refcounts
are not a major issue (but maybe I'm overlooking something).

> Jython right now use the switch thing in some cases, but I suspect it is 
> not JIT inlining friendly so a lot of inner classes are preferable.

Good to know.  Well, I guess we'll have to try both and compare, anyway.

A bientôt,


More information about the Pypy-dev mailing list