Towards faster Python implementations - theory

[Kay Schluehr]

On May 9, 1:25 pm, John Nagle <n... at animats.com> wrote:
> Marc 'BlackJack' Rintsch wrote:
> > I don't see how this type inference for static types will work unless some
> > of the dynamism of the language will get restricted.  But is this really
> > necessary?  Isn't a JIT compiler and maybe type hinting good enough?
>
>     Not necessarily.  One of the more powerful optimizations is to optimize
> reference count updates.   Often, you can hoist reference count updates
> out of loops, which is a big win.  But to do that, you need to be sure
> that the code executed by the loop won't change unexpectedly.

The advantage of having a JIT is just that it can record data at
runtime and respond flexible to them. It doesn't run into global
static analysis problems mentioned by Paul. A "semi-dynamical"
compromise would mean to use a profile of samples of runtime data and
assert that they reflect typical" behaviour. Then the system needs an
ability to fall back to usual bytecode interpretation. Psyco does that
by analyzing the next opcode and a very clever dispatch mechanism.

A more code oriented, profile driven approach would factor source into
natively compilable parts and those that have to be bytecode
interpreted. I wonder whether bridges to Pyrex, Boost.Python or the
celerid bridge to D could be used and what the performance penalties
are for all the argument/return value wrapping and unwrapping.
Unfortunately ShedSkin lacks CPython integration. We talked about this
here recently.

Kay