pyvm -- faster python

[François Pinard]

[Paul Rubin]

> François Pinard <pinard at iro.umontreal.ca> writes:
>
> > Deep down, why or how not having a [traditional, to-native-code]
> > compiler is a deficiency for CPython?  We already know that such a
> > beast would not increase speed so significantly, while using much
> > more memory.

> I'd say the opposite.  The 4x speedup from Psyco is quite significant.
> The speedup would be even greater if the language itself were more
> compiler-friendly.

Psyco is not a traditional compiler.  Compilation occurs at run-time, as
typing information is not available without observation.

> > So far, it seems that the only way to get speed is to attach static
> > type information to some variables.

> No of course not, there's quite a bit of overhead in interpretation in
> general.  Plus, having to do a dictionary lookup for 'bar' in every
> call like foo.bar() adds overhead and I don't think I'd call fixing
> that as similar to adding static type info.

The dictionary lookup does not occur for local variables.  Changes are
planned in Python so lookups may be avoided in a few cases of global
variables.  But until (and despite!) such changes occur, compilation
does not buy you much, here.  This has been much studied and debated.

> > Some compilation avenues do it through information added either in
> > Python source code or in extraneous declarative files, other
> > approaches do it by delaying compilation until such information is
> > discovered at run-time.

> Also, lots of times one can do type inference at compile time.

Yes, particularily in simple or small programs.  I vaguely remember
that the unborn Viper (or Vyper?) was promising compile time type
inference.  It seems that so far, in many years, no one really succeeded
in demonstrating a definite advantage in this direction, at least, not
enough for the community to follow in.

> > The former taints the purity of real CPython as the only source.

> I don't understand this.  What purity?  Why is real CPython the
> only source?  There are dozens of C compilers and none of them is
> the "only source".  Why should Python be different?

Because it is.  There are not dozens of Python compilers.  A few, maybe.

Pyrex gives me a lot of speed, given I taint my Python sources with
cdefs, ctypes, etc.  Oh, I'm absolutely happy with Pyrex when I starve
for speed, but I know and you know that we are not writing pure Python
then.  And if, for not touching sources, one supplements them with
separate declarative files, my Python code may look pure, but I have to
maintain those files as well, and Python is not my only source anymore.

So, to get back to the origin of our argument, I'm still not tempted
to think that Python not having a compiler makes it deficient, because
having a compiler (at least in the traditional acceptation of the term)
would not buy it much enough.

-- 
François Pinard   http://pinard.progiciels-bpi.ca