Home Original page

One Python 2.1 idea

rturpin at my-deja.com rturpin at my-deja.com
Sun Dec 24 15:19:54 EST 2000 
In article <mailman.977684587.22689.python-list at python.org>,
  "Tim Peters" <tim.one at home.com> wrote:
[Lieven Marchand]
>> I think Common Lisp shows that getting very good
>> speed in Python is quite feasable. ..

In article <mailman.977684587.22689.python-list at python.org>,
  "Tim Peters" <tim.one at home.com> wrote:
> The reasons vary, in large part depending on whether
> or not they've ever worked on a compiler <wink>.  Whatever,
> the fact is that there isn't a Python compiler, nor a
> credible plan for such a beast to come into existence.

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. Can the
code for list comprehensions be made faster? Does the
existing front-end pre-execute all constant (sub)expressions?
Does it pre-construct fields and methods that are NOT
conditional in class and constructor definitions? Does it
bind constant references to these as tightly as possible?
Are there extensions to the byte code that would increase
efficiency? (And maybe I'm wrong. Maybe most of the low
hanging fruit has been plucked.)

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.

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

Russell


Sent via Deja.com
http://www.deja.com/
More information about the Python-list mailing list