pyvm -- faster python

[Stelios Xanthakis]

Hi,

Kay Schluehr wrote:
> 
> Why this? eval() consumes a string, produces a code object and executes
> it. Wether the code-object is bytecode or a chunk of machine code makes
> a difference in the runtime but does not alter the high level
> behavioural description of eval(). In either way the compile() function
> behind eval is a JIT.
> 

It makes a difference because
1) You depend on a compiler. Especially if you want to optimize the
machine code you depend on a big program (no tcc for example)
2) Optimizing machine code, needs a lot of code/time.
3) What about debugging info? Dwarf?
4) What if there's a new architecture?

The bytecode compiler is *much* faster to produce the bytecode assembly.


Also, for the other part of the thread, I think that bytecode may
be in fact faster than machine code JIT.  Here is a theory:

Suppose that for each algorithm there is the "ideal implementation"
which executes at the speed limit where it can't be done any faster.
For small algorithms the speed limit may be known but for more
complex programs, it's just a theoretical limit.  Now for such very
big programs bytecode has the advantage that it achieves very good
code re-use;  everything is those 400kB of the libpython core and that
does not increase with the size of the program.  In this case, bytecode
is the driver that operates the buldozer (the buldozer being C).  So the
theory is that for very complex programs a bytecode+core-library is
closer to the ideal implementation than a JIT which produces/compiles
megabytes of machine code.

Evidence for that may be that all those JIT efforts don't get any
great speed ups (psyco is different as it exposes static-ness).

Of course, if we care about speed we'll use Pyrex to convert some
heavy routines to C.  For example if we need FFT, it's madness to
do it in the HLL.  Make it part of the buldozer.



Stelios