RE: overriding built-ins

Discussion in 'Python' started by Pettersen, Bjorn S, Oct 2, 2003.

  1. > From: dan [mailto:]
    >

    [...]
    >
    > However that brings up an interesting issue: the plethora of new
    > languages with bytecode interpreters (Java, Python, C#) are starting
    > to concern me. It seems like there could be a place for some sort of
    > standardized, low-level bytecode syntax, so that work on things like
    > JIC compilation can occur independently of high-level changes and
    > alternatives to source syntax.

    [...]

    First the Python VM (PVM) is very different from the JVM, and CLR which
    you mention. Both the JVM and the CLR use relatively low-level byte
    codes while the PVM byte-codes are strongly tied to the Python language.
    For just-in-time (JIT) compilation to be worth the effort you need
    low-level byte codes (not entirely true, but close ;-). The Python byte
    codes, implmented in highly optimized C, are hard to improve with a
    simpleminded scheme.

    That said, there's work on a new VM for Perl, Python, and probably other
    VHLLs, http://www.python.org/parrot.html (I could give you the direct
    link, but what fun would that be :)

    The JVM has been targetted by many research projects, probably best
    known is the Pizza language/java-superset:
    http://pizzacompiler.sourceforge.net/.

    The CLR, which is compiled before execution (i.e. strictly speaking C#
    doesn't use a bytecode interpreter :), is of course trying to be all
    things to all people but has been struggeling with a primitive type
    system. Work has been done to add F-bounded parametric polymorphism
    (think c++ templates with [interface] constraints on the template
    arguments [much simplified]). An interesting paper is:
    http://research.microsoft.com/projects/clrgen/generics.pdf.

    Dynamic recompilation can augment VM execution, e.g.:
    http://www.cs.ucsb.edu/labs/oocsb/papers/pldi94.pdf

    VHLLs _can_ of course be compiled directly to machine code, the Vortex
    compiler of the Cecil project used to have a SmallTalk front end
    (http://www.cs.washington.edu/research/projects/cecil/www/Release/).

    For an interesting approach, there is domain specific VM generation,
    where the compiler emits a higlhy specialized VM 'dialect' for the
    program at hand
    (http://www.usenix.org/publications/library/proceedings/javavm02/full_pa
    pers/venugopal/venugopal_html/).

    Theoretically, the best combination of speed and flexibility can be
    achived by specializing compilers, like e.g. Psyco
    (http://psyco.sourceforge.net/).

    As you can see, there is no real consensus on what the best approach is,
    or even if there is one. While the Cecil approach sounds like what
    "everyone" wants, the tradeoff is hours of compilation time... For now
    it's probably good to have a plethora of VMs.

    -- bjorn
     
    Pettersen, Bjorn S, Oct 2, 2003
    #1
    1. Advertising

  2. Pettersen, Bjorn S

    John Roth Guest

    "Pettersen, Bjorn S" <> wrote in message
    news:...
    > From: dan [mailto:]
    >

    [...]
    >
    > However that brings up an interesting issue: the plethora of new
    > languages with bytecode interpreters (Java, Python, C#) are starting
    > to concern me. It seems like there could be a place for some sort of
    > standardized, low-level bytecode syntax, so that work on things like
    > JIC compilation can occur independently of high-level changes and
    > alternatives to source syntax.

    [...]

    First the Python VM (PVM) is very different from the JVM, and CLR which
    you mention. Both the JVM and the CLR use relatively low-level byte
    codes while the PVM byte-codes are strongly tied to the Python language.
    For just-in-time (JIT) compilation to be worth the effort you need
    low-level byte codes (not entirely true, but close ;-). The Python byte
    codes, implmented in highly optimized C, are hard to improve with a
    simpleminded scheme.

    That said, there's work on a new VM for Perl, Python, and probably other
    VHLLs, http://www.python.org/parrot.html (I could give you the direct
    link, but what fun would that be :)

    The JVM has been targetted by many research projects, probably best
    known is the Pizza language/java-superset:
    http://pizzacompiler.sourceforge.net/.

    The CLR, which is compiled before execution (i.e. strictly speaking C#
    doesn't use a bytecode interpreter :), is of course trying to be all
    things to all people but has been struggeling with a primitive type
    system. Work has been done to add F-bounded parametric polymorphism
    (think c++ templates with [interface] constraints on the template
    arguments [much simplified]). An interesting paper is:
    http://research.microsoft.com/projects/clrgen/generics.pdf.

    Dynamic recompilation can augment VM execution, e.g.:
    http://www.cs.ucsb.edu/labs/oocsb/papers/pldi94.pdf

    VHLLs _can_ of course be compiled directly to machine code, the Vortex
    compiler of the Cecil project used to have a SmallTalk front end
    (http://www.cs.washington.edu/research/projects/cecil/www/Release/).

    For an interesting approach, there is domain specific VM generation,
    where the compiler emits a higlhy specialized VM 'dialect' for the
    program at hand
    (http://www.usenix.org/publications/library/proceedings/javavm02/full_pa
    pers/venugopal/venugopal_html/).

    Theoretically, the best combination of speed and flexibility can be
    achived by specializing compilers, like e.g. Psyco
    (http://psyco.sourceforge.net/).

    As you can see, there is no real consensus on what the best approach is,
    or even if there is one. While the Cecil approach sounds like what
    "everyone" wants, the tradeoff is hours of compilation time... For now
    it's probably good to have a plethora of VMs.

    [John Roth adds... ]

    I could also add the PyPy project to reimplement Python in
    Python; they think they will be able to integrate a Psyco style
    JIT with it eventually.

    Also of note is that the current Perl VM is very high level as
    well.

    And that Python has been implemented on top of the JVM,
    but it runs quite slowly because of a mismatch between Java's
    static typing and Python's dynamic typing.

    Also, the project to implement Python on top of the .NET
    CLR died because of massive performance problems.

    John Roth


    -- bjorn
     
    John Roth, Oct 2, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dan

    overriding built-ins

    dan, Sep 28, 2003, in forum: Python
    Replies:
    7
    Views:
    422
    Andrew Dalke
    Oct 2, 2003
  2. Marco Aschwanden
    Replies:
    3
    Views:
    300
    Carlos Ribeiro
    Sep 3, 2004
  3. Carlos Ribeiro
    Replies:
    3
    Views:
    295
  4. Jp Calderone
    Replies:
    3
    Views:
    286
    Carlos Ribeiro
    Sep 6, 2004
  5. Carlos Ribeiro
    Replies:
    30
    Views:
    763
    Alex Martelli
    Sep 9, 2004
Loading...

Share This Page