Towards faster Python implementations - theory

[John Nagle]

Some faster Python implementations are under development.
JPython has been around for a while, and PyPy and ShedSkin
continue to move forward. It's worth thinking about what slows
down Python implementations .

It isn't the dynamism, really. As others have pointed out
in the Python literature, most of the time, the more elaborate
dynamic features aren't being used for any given variable or
object. If code has something like "x = 1.0", the odds are that
"x" is going to stay a floating point number, and not suddenly turn
into a list or an object reference. The type inference of Shed Skin
builds on that assumption, adding some restrictions about changing of
variable types.

The Shed Skin effort indicates that explicit typing, via 'decorators'
or otherwise, isn't really necessary. What's necessary is the avoidance
of "surprises" in the language. In this context, a "surprise" is
the use of a dynamic feature in a way that can't be seen at compile time.

A typical "surprise" would be the use of "setattr" on an object from
outside the compilation unit that defines the object. Within a module,
"setattr" on an object in that module is no problem; the compiler can see
it and generate the extra machinery needed to make an object dynamically
alterable at run time. But if an object doesn't need that extra machinery
and associated dictionary, it's a big win to discard the excess baggage
and use a simpler fixed-size representation, comparable to a C struct,
for the object.

On the typing front, the neatest way to express typing is via
initialization. With the Shed Skin restrictions, if all variables are
initialized before use (preferably in __init__), there's no need to
maintain an "undefined" flag for a variable. And, of course, if
the type of a varaible is simple and can't change, it doesn't have to
be "boxed", (enclosed in an object) which is a big win.

The point here is that we don't need language changes or declarations
to make Python much faster. All we need are a few restrictions that
insure that, when you're doing something unusual, the compiler can
tell.

John Nagle

[sturlamolden]

On May 10, 4:02 pm, Tim Golden <m...@timgolden .me.ukwrote:

But the relevant bit of your last paragraph is at the start:
"We should...".

Sorry, bad choice of words.

see it faster. That's great. But unless people
puts their money where their mouths are, I don't

I know, I know. But that doesn't stop me from envying what the Lisp
community has achieved.

Python still sucks if we are using it for scientific simulations,
testing CPU-bound algorithms, etc. Sure it is only 150-200 times
slower than C for these tasks, but that can amount to the difference
between one day and half a year of CPU time. But as strange as it may
seem, it can still be advantageous to use Python. E.g. it may be less
expensive to run the simulation in parallel on 200 CPUs than writing
the code in C instead of Python.

[sturlamolden]

On May 10, 7:18 pm, "Terry Reedy" <tjre...@udel.e duwrote:

Unfortunately, native machine code depends on the machine, or at least the
machine being emulated by the hardware. Fortunately or not, the dominance
of the x386 model makes this less of a problem.

CMUCL and SBCL depends on the dominance of the x86 architecture.

GCL uses the GCC backend, which supports a wide range of
architectures.

Building a compiler backend is not needed for a Python JIT, one can
accept the GPL license and use GCC as a backend.

Or one could translate between Python and Lisp on the fly, and use a
compiled Lisp (CMUCL, SBCL, Franz, GCL) as runtime backend.

[John Nagle]

Tim Golden wrote:

sturlamolden wrote:

>On May 8, 5:53 pm, John Nagle <n...@animats.c omwrote:

>> The point here is that we don't need language changes or
declaration s
to make Python much faster. All we need are a few restrictions that
insure that, when you're doing something unusual, the compiler can
tell.

I doubt if anyone disputes the gist of what you're
saying[*], viz that Python could be made faster by using
technique (a), (b) or (c) which have been successful elsewhere. At least
that it's worth investgating.

But the relevant bit of your last paragraph is at the start:
"We should...". Unless someone or someones has the time,
inclination, money, backing, wherewithal etc. to implement
this or any other measure of speeding-up, it's all
pie-in-the-sky. Useful, maybe, as discussion of what
options are viable, but a project of this magnitude
doesn't just happen in some developer's lunchbreak.

Focusing may help. Between Jython, PyPy, and Shed Skin,
enough effort has been put in to produce something better than
CPython, but none of those efforts resulted in something more
useable than CPython.

There's a "commercial grade Python" from ActiveState, but
that's CPython in a cardboard box, I think.

Another problem is that if the language is defined as
"whatever gets put in CPython", that discourages other
implementations . The language needs to be standards-based.

John Nagle

[Paul Boddie]

On 11 May, 18:04, John Nagle <n...@animats.c omwrote:

>
Another problem is that if the language is defined as
"whatever gets put in CPython", that discourages other
implementations . The language needs to be standards-based.

Indeed. This was suggested by one of the speakers at last year's
EuroPython with reference to the various proposals to remove map,
reduce, lambda and so on from the language. The opinion was that if
Python implementations change and leave the users either on
unsupported releases or with the work of migrating their code
continuously and/or to features that they don't find as intuitive or
appropriate, some people would rather migrate their code to a language
which is standardised and which can remain agreeable for the
foreseeable future.

Paul

[Terry Reedy]

"sturlamold en" <st**********@y ahoo.nowrote in message
news:11******** **************@ e65g2000hsc.goo glegroups.com.. .
| On May 10, 4:02 pm, Tim Golden <m...@timgolden .me.ukwrote:
| I know, I know. But that doesn't stop me from envying what the Lisp
| community has achieved.

But do not let your envy stop you from noticing and appreciating what the
Python commnunity has achieved.

| Python still sucks if we are using it for scientific simulations,

Not if you use extensions compiled from C or Fortran. Doing so is not
cheating, any more than using the C-coded methods of the builtin types.
Leveraging existing code and compilers was part of Python's design.

With the Numeric extensions, produced by people at the US nuke labs.
scientific simulations were, I think, Python's first killer ap.

| Sure it is only 150-200 times slower than C for these tasks,

As a general statement, nonsense. A LinPack inversion of a 10k x 10k
matrix takes the same time whether called from Python or a C program. The
miniscule extra overhead of Python is more than made up for by the ability
to call LinPack and other functions interactively.

The extended buffer protocol, championed by Travis Oliphant and slated for
3.0, will make cooperation between extensions much easier.

Terry Jan Reedy

[Robert Brown]

sturlamolden <st**********@y ahoo.nowrites:

On May 10, 7:18 pm, "Terry Reedy" <tjre...@udel.e duwrote:

CMUCL and SBCL depends on the dominance of the x86 architecture.

CMUCL and SBCL run on a variety of architectures, including x86, 64-bit x86,
PowerPC, Sparc, Alpha, and Mips. See

http://www.sbcl.org/platform-table.html

for platform support information.

Or one could translate between Python and Lisp on the fly, and use a
compiled Lisp (CMUCL, SBCL, Franz, GCL) as runtime backend.

This has been done by Willem Broekema. PLPython is a Python implementation
that translates Python source into Common Lisp at read time. Under the
covers, the Lisp is compiled into machine code and then run. See

http://trac.common-lisp.net/clpython/

Currently, CLPython uses some non-standard Allegro Common Lisp features, so
it does not run on all the free implementations of ANSI Common Lisp. The
implementation is interesting, in part because it shows how expensive and
complex some Python primitives are.