One Python 2.1 idea

[Tim Peters]

[rturpin at my-deja.com]
> Making Python faster doesn't require the creation of an
> optimizing compiler, complete with data and control flow
> analysis, loop unrolling, expression optimization, code
> unfolding, etc.
>
> There likely would be a lot of bang for the buck from
> small improvement to the existing infrastructure.

Except that everyone who has been interested in pursuing such things has
been doing so for a decade.  CPython is probably about 4x faster today than
it would have been otherwise.  There don't appear to be many *simple*
changes left that are clearly "worth it".

> Can the code for list comprehensions be made faster?

Sure.  "bang for the buck" is limited by how often a particular trigger is
pulled, though, and listcomps are currently barely used.  This isn't a
technical problem, it's a problem of finding someone motivated enough to
bother doing something about it.  You're not -- and neither am I.

> Does the existing front-end pre-execute all constant (sub)
> expressions?

Python does no source optimizations whatsoever today:  WYSIWYG.  If you
write

    x = 1 + 2 + 3

then at runtime it will load 1, load 2, add them, load 3, add that to the
sum of 1+2, then store the result into x.  It doesn't much matter, though:
this isn't C, and there's no preprocessor generating gobs of constant
expressions to *be* folded.  Nobody writes "x = 1 + 2 + 3".  They *may*
write

    X = 1 + 2 + 3

at top level to define a module-level (conceptual) constant, but in that
case again it's not C, and that isn't a macro -- the computation is a
one-time module startup cost, and so speeding it would be an academic
exercise of no practical value.

> Does it pre-construct fields and methods that are NOT
> conditional in class and constructor definitions?

Nope.  Although I'm not sure how you're going to determine whether a thing
is conditional without some flow analysis <wink>.

> Does it bind constant references to these as tightly as possible?

Ditto.

> Are there extensions to the byte code that would increase
> efficiency?

That's been looked at extensively.  The most promising idea along those
lines was to switch from a stack-based VM to a 3-address register-based one
(Skip Montanaro's "Rattlesnake" project).  It's not a huge win, though --
the base problem is that, e.g., in "x + y", Python has no idea at compile
time what "+" may mean, and so regardless of bytecode model it's going to
pump out *something* that says "ok, it's a binary add, now you figure out
the types of x and y, whether coercions are necessary, whether they're class
instances that supply __add__ and/or __radd__ methods, and do something
appropriate with all that".  Breaking that mess into smaller bytecodes would
only slow things down, via forcing that many more trips around the eval
loop.  Moving to a register-based VM would yield a small speedup via
allowing to skip a few trips around the eval loop (the loads and the store
would be specified in the "+" opcode directly, instead of being spread
across 3 other bytecodes).

Before you suggest it <wink>, note that Guido has always been repelled by
the idea of generating more than one bytecode sequence to do a thing and
letting a runtime test decide which sequence would be cheaper.

> (And maybe I'm wrong. Maybe most of the low hanging fruit has
> been plucked.)

Mostly, yes.  There are a number of patches out there that buy 10-15% by
rewriting the eval loop in excruciating-- and usually
platform-dependent --ways, but they exceed Guido's pain threshold.  That is,
they would make the code harder to maintain than they're worth, in his
opinion (mine too, but only his counts ...).

> I guess this is my fault, for saying "speed." And yeah, I
> would love a full, optimizing, JIT compiler with portable
> code generation, so it lives on all platforms. But we all
> know that isn't happening any time soon, unless some
> company bellies up to the bar with money to make it happen.

Note that it's not a universal desire.  I made my living for 15 years
working on optimizing compilers, and one of the things I loved from the
start about Python is that I have never burned any of my time tracking down
a Python optimization bug (it's hard to introduce an optimization bug when
you don't do any <wink>).  OTOH, Python developers have lost countless hours
(and movies, and reunions with friends, and trips, and sleep ...) to
tracking down optimization bugs in the C compilers used to compile Python.
And a bug in a JIT makes that look like a pleasure.  Like everything else,
"optimization" has real downsides.

> I was pushing merely for modest efforts in this direction.
> I can only push, since my time is devoted elsewhere.

Alas, I'm not sure you're going to find anyone on the receiving end of the
nudge.

my-python-code-runs-5x-faster-this-month-thanks-to-dumping-$2K-
    on-a-new-machine-ly y'rs  - tim