pyvm -- faster python

[Mike Meyer]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> 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.

The DEC Scheme->C compiler (yes, it was an honest to gods compiler -
it just generated C instead of machine code) doesn't sound very
similar to generating C code from byte code. The latter sounds like a
straightforward translation of byte code to C.  The Scheme->C
compiler, on the other hand, used all the optimizations known to LISP
compiler writers. It would, with the right settings, produce code that
was comparable to hand-coded C. So unless the Python compiler that
produced the byte code in the first place does all those optimizations
(which I don't know), you're not going to get results that compare
with the Scheme->C system.

> 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.

There are people out there who claim that compiling carefully coded
LISP can compete with compiling carefully coded C. They use such
systems in real-world, time-critical applications. The thing is, to
get that performance, they had to go back and tell the compiler what
the types of all the variables are, and disable all the runtime type
checking.

So if this is a real goal, you now have some idea of what to look
forward to in Python's future.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.