pyvm -- faster python

[Kay Schluehr]

Stelios Xanthakis wrote:
> Kay Schluehr wrote:
>
> >
> > Yes. What we are seeking for and this may be the meaning of Armins
> > intentiously provocative statement about the speed of running HLLs
is a
> > successor of the C-language and not just another VM interpreter
that is
> > written in C and limits all efforts to extend it in a flexible and
> > OO-manner. Python is just the most promising dynamic OO-language to
> > follow this target.
> >
>
> Bytecode engine is the best method for dynamic code execution
> ("exec", eval, etc).  A low level OOP language would be very suitable
> for a python VM.

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.

> pyvm has that. A big part of it is written in "lightweight C++" [1].
> That makes it less portable as the lwc preprocessor is using GNU-C
> extensions.

Hmmm... I'm not amazingly happy that it is not ANSI-C++. To be honest I
don't want to learn lw-C++ and the peculiaritys of the translator and
debuging through translated code. This may be an interesting study on
it's own but it is just not me who is interested in it. Using an
experimental language to write an experimental VM is clearly out of my
motivation ( only as a remark for the quest of contribution not as a
general criticism ).

> However, it's the same extensions also used by the linux
> kernel and AFAIK the intel compiler supports them too.
>
> So probably the bigger "competitor" of pyvm is boost-python.

How could boost-Python be a "competitor"? Isn't it just an ANSI
C++-binding that relates heavily on templates that are not even
supported by lw-C++?

Regards,
Kay