pyvm -- faster python

[Paul Rubin]

Andrew Dalke <dalke at dalkescientific.com> writes:

> Years ago, presented at one of the Python conferences, was a program
> to generate C code from the byte code....  The conclusion I recall
> was that it wasn't faster - at best a few percent - and there was a
> big memory hit because of all the duplicated code.  One thought was
> that the cache miss caused some of the performance problems.  Does
> that count as a compiler?

I would say it counts as a compiler and that other languages have
used a similar compilation approach and gotten much better speedups.
For example, Java JIT compilers.  The DEC Scheme-to-C translator
and Kyoto Common Lisp also produced C output from their compilers
and got really significant speedups.  Part of the problem may be
with the actual Python language.  One of the reasons for wanting
real compilation as a high priority, is that the presence of a
compiler will affect future evolution of the language, in a way
that makes it more conducive to compilation.

Despite the shrieks of the "Python is not Lisp!" crowd, Python
semantics and Lisp semantics aren't THAT different, and yet compiled
Lisp implementations com completely beat the pants off of interpreted
Python in terms of performance.  I don't think Python can ever beat
carefully coded C for running speed, but it can and should aim for
parity with compiled Lisp.