Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: overriding built-ins

Reply
Thread Tools

RE: overriding built-ins

 
 
Pettersen, Bjorn S
Guest
Posts: n/a
 
      10-02-2003
> From: dan [(E-Mail Removed)]
>

[...]
>
> 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/projec...n/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/researc.../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/l...vavm02/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

 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      10-02-2003

"Pettersen, Bjorn S" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> From: dan [(E-Mail Removed)]
>

[...]
>
> 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/projec...n/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/researc.../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/l...vavm02/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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Need help with overriding generic in top level fastgreen2000@yahoo.com VHDL 9 02-10-2005 05:54 PM
Redistribute static to OSPF, overriding the slower OSPF-native route? E.Finlayson Cisco 0 09-10-2004 02:13 PM
overriding,shadowing concept sangam via .NET 247 ASP .Net 1 06-23-2004 03:46 AM
A design ( inheriteance / overriding ) question sourabh ASP .Net 1 05-21-2004 06:25 AM
Overriding functionality of an entity is prohibited? Valentin Tihomirov VHDL 10 11-03-2003 07:41 PM



Advertisments