a basic bytecode to machine code compiler

[John Nagle]

On 4/2/2011 3:30 AM, Stefan Behnel wrote:
> Cython actually supports most Python language features now (including
> generators in the development branch), both from Python 2 and Python 3.
> Chances are that the next release will actually compile most of your
> Python code unchanged, or only with minor adaptations.

     Cython requires the user to insert type declarations, though, to
get a speed improvement.

     Shed Skin has a good type inference system, but it insists on
a unique type for each object (which includes "null"; a type of
"str or null" is not acceptable).  The rest of Shed Skin, outside
the type inference system, is not very well developed.

     There's a path there to a fast Python with some restrictions.
The Shed Skin inference engine with the Cython engine might have
potential.

     PyPy gets some speedups, mostly by recognizing when numbers can be
unboxed.  (CPython carries around a CObject for every integer; that's
what's meant by "boxing")  But outside of number-crunching, PyPy
doesn't show big gains.  And the whole PyPy JIT system is far
too complex.  They try to retain all of Python's dynamism, and
as a result, they need to be able to bail from compiled code
to one of two different interpreters, then recompile and go
back to compiled mode.

     Unladen Swallow failed to produce much of a speed improvement
and Google pulled the plug.  It's time to look at alternatives.

     There's no easy way to speed up Python; that's been tried.
It needs either a very, very elaborate JIT system, more complex
than the ones for Java or Self, or some language restrictions.
The main restriction I would impose is to provide a call that says:
"OK, we're done with loading, initialization, and configuration.
Now freeze the code."  At that moment, all the global
analysis and compiling takes place.  This allows getting rid
of the GIL and getting real performance out of multithread
CPUs.

				John Nagle