pyvm -- faster python

[Terry Reedy]

"Stelios Xanthakis" <sxanth at ceid.upatras.gr> wrote in message 
news:42847381.9010800 at ceid.upatras.gr...

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

This, of course, is exactly what CPython does.  Bytecodes index into a 
switch table that jumps to interface code that calls C routines, most of 
which have been optimized, on and off, for about 15 years.

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

And of course, it already is (replacing 'bulldozer' with 'set of 
construction equipment'), under the name NumPy or Numarray.  And both of 
these can take advantage of an Atlas implementation of the BLAS, when 
available, that is tuned to a specific platform with the intention of being 
the 'ideal implementation' of the Basic Linear Algebra Subroutines for that 
platform.

So I congratulate you on conceptually re-inventing Python + C extensions. 
But I haven't understood yet what conceptual variations you have or plan to 
make on the current implementation.

Current CPyVM simulates a stack machine.  This has the virtual of 
simplicity and clarity even for someone like me who has never seriously 
written assembler. People have made proposals to switch to simulating a 
(more complex) register machine, with a new set of bytecodes, that 
theoretically would be faster.  Do you have any opinion on this issue?  You 
seem to like the current byte code set while wanting to run faster.

Terry J. Reedy