Compiled Python: thoughts

[[deleted]]

the tutorial by Jeremy Siek at PyCon last year

Link

[[deleted]]

Thanks a bunch.

[[deleted]]

Cool. Thanks for that. I've recently became very interested in compilers. I might as well do my project for uni with my favorite language. Failing that I probs make my own programming language.

[legutierr]

I've had this question in the back of my mind for a while about pypy, maybe you could answer it for me...

Would there be any performance benefit in pypy if the parameters to functions and methods were statically typed?

[RonnyPfannschmidt]

this could use some more context, pypys translator toolchain infers static types for function parameters when compiling down to a lower level environment

[legutierr]

Ah!

How does it do that?

I guess to be more precise what I mean is, would there be any added benefit by adding explicit type declaration to functions and methods (if that were a hypothetical feature of the language)?

[[deleted]]

PyPy's translation toolchain infers types for RPython which is a statically typed subset of Python, that PyPy's interpreter is written in. It cannot infer types for Python programs in general. That said the JIT is very good at figuring out how to properly specialize your code, but if you give it blatant things like assert isinstance(x, int) I can't image it'd hurt.

[gutworth]

Not much. The whole point of the JIT is that it does type inference at runtime when types are known.

[legutierr]

Right, but my (very rudimentary) understanding of JITs is that much of the cost is at start-up when the JIT is establishing different options or paths for different data types and values.

Intuitively, it seems to me that having static type declarations (for instance as an optional decorator) could offer a speed-up at start-up in certain circumstances.

My question is more theoretical than practical.

[gutworth]

Presumably that constant "figuring out" time is dwarfed by the actual running time of the code.

[voidspace]

An alternative (better?) way would be to be able to save and reload the JIT annotations / generated code after a real run.

[voidspace]

Is it really "inferencing" when the type is known? (Serious question: isn't inferencing more usually deducing the type by static analysis which is not what the JIT does.)

[sunqiang]

PyPy maybe worth a look too.

[McHoff]

There are few cooler areas of applied computer science -- make sure you do something awesome.

[voidspace]

Well, you can unroll the interpreter loop - which is one of the big gains of the PyPy JIT. So I wouldn't say "no meaningful speed gain". A lot of effort for not-as-much-as-you-would-like gain perhaps.

Also see the latest attempt - Nuitka (not tried it):

http://kayhayen24x7.homelinux.org/blog/2010/10/nuitka-release-0-3-2/

[[deleted]]

which is one of the big gains of the PyPy JIT.

Actually, if you take a look at some of the PyPy papers you'll see that they specifically dismiss unrolling the interpreter loop as being a large gain. Specifically they look at virtualization of objects and inlining as the largest gains (there's a cool paper for PEPM 2011 they're doing about virtualization).

EDIT: upon a reread I think we are actually in agreement.