[Python-Dev] Open CPython VM for type information
Kay Schluehr
kay.schluehr at gmx.net
Thu Dec 14 08:38:21 CET 2006
Brett Cannon schrieb:
>
>
> On 12/12/06, *Kay Schluehr* <kay.schluehr at gmx.net
> <mailto:kay.schluehr at gmx.net>> wrote:
>
> Dear Python developers,
>
> while the JVM is opened to support dynamically typed languages [1] I
> wonder if the CPyVM could not show more openness to statically typed
> languages? Hereby I don't think that much about arbitrary
> languages for
> the CPyVM but sublanguages like RPython which are "static enough"
> to be
> compilable into extension modules [2].
>
> However creating C extension modules from Python code is not
> really the
> standard way I do think Python source should be handled. Instead I
> think
> about a more direct VM support like the JVM does, that provides
> opcodes
> like iload, fstore etc. Besides this I don't expect one canonical
> approach for these type information to be feeded into the CPyVM. There
> are type inferencer like rtyper for PyPy, Psycos continous bytecode
> monitoring and also other approaches are possible that use type
> feedback. Finally optional type declarations are also an issue;
> however
> I would like to see language design discussions being separated ( ->
> Python 3000 ) and focus on general APIs for compiler extensions /
> plugs
> that deal with type information ( the architecture ) and VM
> implementation issues.
>
> Thanks, Kay
>
> [1] http://jcp.org/en/jsr/detail?id=292
> [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html
>
>
> The Python VM is not designed to be general-purpose, period. Nor does
> anyone on python-dev, to my knowledge, have any interest in putting
> the time and energy into making it general. I am quite happy with
> letting the Parrot folk handle this goal. This means that the
> maintenance cost of adding more opcodes is not worth it.
>
> But a bigger issue with me is the performance hit. Every opcode will
> make the eval loop larger. And it is known that the eval loop is
> rather finicky in terms of size and performance. While no hard
> testing has been done, it has been assumed we have accidentally hit
> the sweet spot in terms of CPU cache size.
>
> An important thing to keep in mind when comparing Python's VM to
> Java's is that Java works (somewhat) for dynamic languages because
> people are motivated enough to shoehorn languages into it by just
> assuming everything is just an object and tossing out the type
> checking inherent to Java. But Java has not, to my knowledge, grown
> any great features yet to make dynamic languages work better. I know
> about JSR 292, but that is not in yet and adding just one opcode is
> not that expensive to the JVM. But compare the cost of adding a slew
> of typed opcodes to Python compared to the JVM adding just one is not
> really equal.
>
> In other words, I wouldn't count on this ever happening. =) The best
> you could do is try to propose some direct mechanism for adding
> support to the eval loop to dispatch to some function for unrecognized
> opcodes, but I wouldn't count on that being accepted either.
>
> -Brett
Brett, thanks for the short answer. Although it is negative regarding my
attempt, it is also important to know which ideas are outlawed and where
one steps into a no-go area concerning the evolving language standard
and its main implementation.
Regards
More information about the Python-Dev
mailing list