The compiler canard

Lulu of the Lotus-Eaters mertz at gnosis.cx
Thu Oct 9 21:08:44 EDT 2003


|> |Do they ever plan to do a compiler for it [Python]?
|> You mean like Psyco?

Kenny Tilton <ktilton at nyc.rr.com> wrote previously:
|Oh, excellent name.  OK, the context was "what are Python's
|aspirations?"  Is Python now no longer content to be a (very powerful)
|scripting language?  Or is it just tired of being ragged on for being
|slow?

Python never had an "aspiration" of being "just a scripting language",
nor WAS it ever such a thing.  From its release, Python was obviously a
language very well suited to large scale application development (as
well as to short one-off scripts).

There -is- sometimes a misguided allegation that Python is slow.  It's
not.  Certainly Python is faster than most of the languages with
commercial backers who make such claims (e.g.  Java, VB).  But indeed,
for a class of applications, pure Python is not a good choice--for
long-running, complex, scientific calculation, Fortran or C are much
better (becaue they run many times faster).

There are several approaches, however, to making applications written
mostly in Python faster (in the fairly unusual case that it needs to be
faster).  One is to use extension modules--usually coded in C--to handle
the bottlenecks.  Y'know, 90% of program time spent in 10% of the code,
or whatever--rewrite that 10% in C. Numerical Python is a widely used
example of this approach.

A second approach is similar:  You can use Pyrex to write these
extension modules in a language that is *almost* Python.  While Pyrex
syntax is close to Python, under-the-hood, it acts like a code generator
for C... so in the end, you still get an extension module.

A third approach is the simplest of all (for the end programmer, not for
Armin Rigo :-)):  Use the Python Specializing Compiler (Psyco).  Psyco
is a cool tool to dynamically generator x86 assembly for code paths in
Python bytecodes.  Basically, the same thing as a JIT/HotSpot
environment for Java (there are some differences in exactly how it
works, but from 30,000 feet it's the same idea).  Of course, no one has
ported Psyco to my Macs yet... but using it on my PCs amounts to adding
less than a half dozen (boilerplate) lines to my existing applications,
and speeds up many applications by 5-10x.

Even with the ease of Psyco, I only bother adding it to maybe 5% of the
apps I write.  My 3 year old CPU runs faster than I generally need for
most pure-Python tasks.  Sure, maybe I could speed up some command-line
tool that runs in 5 seconds so that they only take 1 second--but it's
quite rare that I care.  And all the apps that mostly wait on sockets,
keystrokes, etc. just couldn't go any faster either way, since the
constraint is external.

Yours, Lulu...

--
mertz@  | The specter of free information is haunting the `Net!  All the
gnosis  | powers of IP- and crypto-tyranny have entered into an unholy
.cx     | alliance...ideas have nothing to lose but their chains.  Unite
        | against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------






More information about the Python-list mailing list