Is a "real" C-Python possible?

[Paul Rudin]

Re: Is a "real&quot ; C-Python possible?

sturlamolden <sturlamolden@y ahoo.nowrites:

On 10 Des, 23:49, a...@pythoncraf t.com (Aahz) wrote:
>

>"Premature optimization is the root of all evil in programming."
>--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>Hoare)

>
Oh, I was Hoare? Thanks. Anyway, it doesn't change the argument that
optimizing in wrong places is a waste of effort.

Although sometimes people seem to think that it goes "optimisati on is
the root...". The "premature" bit is significant.

[Chris Mellon]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 11, 2007 1:25 PM, John Nagle <nagle@animats. comwrote:

sturlamolden wrote:

On 10 Des, 23:49, a...@pythoncraf t.com (Aahz) wrote:

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
Hoare)

>
We're ten years into Python, and it's still a naive interpreter.

This is an absurd misrepresentati on of the state of the Python VM.

It's time for a serious optimizing compiler. Shed Skin is going
in the right direction. But for some reason, people seem to dislike the
Shed Skin effort. Its author writes "Am I the only one seeing the potential
of an implicitly statically typed Python-likea-lnguage that runs at
practically the same speed as C++?"
>
"For a set of 27 non-trivial test programs (at about 7,000 lines in total;
... measurements show a typical speedup of 2-40 times over Psyco, about 10 on
average, and 2-220 times over CPython, about 35 on average." So that's
what's possible.
>

.... with roughly a hundredth of the python standard library, and a
bunch of standard python features not even possible. I like
generators, thanks.

If shedskin can actually match Pythons feature set and provide the
performance it aspires to, thats great, and I may even start using it
then. But in the meantime, hardly anything I write is CPU bound and
when it is I can easily optimize using other mechanisms. Shedskin
doesn't give me anything that's worth my time to improve on it, or the
restrictions it places on my code. I think JIT is the future of
optimization anyway.

I'm surprised that Google management isn't pushing Guido towards
doing something about the performance problem.
>

Assuming your conclusion (ie, that there's a performance problem to do
something about) doesn't prove your case.

[Hrvoje Niksic]

Re: Is a &quot;real&quot ; C-Python possible?

sturlamolden <sturlamolden@y ahoo.nowrites:

On 10 Des, 23:54, Bruno Desthuilliers
<bdesth.quelque ch...@free.quel quepart.frwrote :
>

>Or a lack of time and money. Lisp is one of the older programming
>languages around, and at a time had BigBucks(tm) invested on it to try
>and make it practically usable.

>
Yes. But strangely enough, the two Lisp implementations that really
kick ass are both free and not particularly old.

Not two, but one -- SBL is simply a fork of CMU CL. As for their age,
the CMU CL states that it has been "continuall y developed since the
early 1980s".

[Steven D'Aprano]

Re: Is a &quot;real&quot ; C-Python possible?

On Tue, 11 Dec 2007 11:25:32 -0800, John Nagle wrote:

sturlamolden wrote:

>On 10 Des, 23:49, a...@pythoncraf t.com (Aahz) wrote:
>>

>>"Premature optimization is the root of all evil in programming."
>>--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>Hoare)

>
We're ten years into Python, and it's still a naive interpreter.
It's time for a serious optimizing compiler. Shed Skin is going in the
right direction. But for some reason, people seem to dislike the Shed
Skin effort. Its author writes "Am I the only one seeing the potential
of an implicitly statically typed Python-like-language that runs at
practically the same speed as C++?"
>
"For a set of 27 non-trivial test programs (at about 7,000 lines in
total;
... measurements show a typical speedup of 2-40 times over Psyco, about
10 on average, and 2-220 times over CPython, about 35 on average." So
that's what's possible.
>
I'm surprised that Google management isn't pushing Guido towards
doing something about the performance problem.

Maybe because it isn't as much a problem as people with C envy assume it
must be? (Disclaimer: I'm not suggesting that John is one of those
people.)

Not that I'd object to anyone else doing the work to speed up Python, but
for the things I use Python for, I've never felt the need to say "Gosh
darn it, my script took twelve milliseconds to run, that's just too
slow!!!". Maybe Google are in the same boat?

Actually, in Google's case, I guess their bottleneck is not Python, but
trying to push around gigabytes of data. That will be slow no matter what
language you write in.



--
Steven.

[Diez B. Roggisch]

Re: Is a &quot;real&quot ; C-Python possible?

John Nagle schrieb:

sturlamolden wrote:

>On 10 Des, 23:49, a...@pythoncraf t.com (Aahz) wrote:
>>

>>"Premature optimization is the root of all evil in programming."
>>--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>Hoare)

>
We're ten years into Python, and it's still a naive interpreter.
It's time for a serious optimizing compiler. Shed Skin is going
in the right direction. But for some reason, people seem to dislike the
Shed Skin effort. Its author writes "Am I the only one seeing the potential
of an implicitly statically typed Python-like-language that runs at
practically the same speed as C++?"
>
"For a set of 27 non-trivial test programs (at about 7,000 lines in
total; ... measurements show a typical speedup of 2-40 times over Psyco,
about 10 on average, and 2-220 times over CPython, about 35 on
average." So that's
what's possible.

No, it's not. Shedskin is interesting, but just a small subset of Python
- and without completeness, performance is useless.

The PyPy approach is much more interesting - first create a
full-featured Python itself, then create optimizing backends for it,
also for just a language subset - RPython.

And if possible - which it is only in a very limited set of cases for
not type-annotated code - identify parts that conform to RPython's
constraints, and compile that JITly.

Diez

[Bruno Desthuilliers]

Re: Is a &quot;real&quot ; C-Python possible?

John Nagle a écrit :

sturlamolden wrote:
>

>On 10 Des, 23:49, a...@pythoncraf t.com (Aahz) wrote:
>>

>>"Premature optimization is the root of all evil in programming."
>>--C.A.R. Hoare (often misattributed to Knuth, who was himself quoting
>>Hoare)

>
>
We're ten years into Python, and it's still a naive interpreter.
It's time for a serious optimizing compiler.

Care to provide a less "naive" one ?

(snip usual rant)

I'm surprised that Google management isn't pushing Guido towards
doing something about the performance problem.

Could it be possible they don't see Python's perfs as a "problem" ?

Ok, I don't mean there's no room for improvement here. If you feel like
addressing the problem, you're welcome - in case you didn't notice,
Python is free software.

[sturlamolden]

Re: Is a &quot;real&quot ; C-Python possible?

On 11 Des, 20:25, John Nagle <na...@animats. comwrote:

Shed Skin effort. Its author writes "Am I the only one seeing the potential
of an implicitly statically typed Python-like-language that runs at
practically the same speed as C++?"

Don't forget about Pyrex and PyPy's RPython.

By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

[Bruno Desthuilliers]

Re: Is a &quot;real&quot ; C-Python possible?

sturlamolden a écrit :
-snip)

We could include optional static typing in
Python,

Please wait - going to get my gun...

[George Sakkis]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 12, 2:18 am, Kay Schluehr <kay.schlu...@g mx.netwrote:

On Dec 12, 7:34 am, sturlamolden <sturlamol...@y ahoo.nowrote:

I am not sure why a new type annotation syntax was needed Python 3:

>
Because people care about a feature when there is @syntax.

Good point; the inverse is not true though: time and time again people
cared about some syntax for properties without any change so far. The
result is a handful of different ways to spell out properties; python
2.6 will add yet another variation (http://mail.python.org/pipermail/
python-dev/2007-October/075057.html).

George

[Kay Schluehr]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 12, 9:04 am, George Sakkis <george.sak...@ gmail.comwrote:

On Dec 12, 2:18 am, Kay Schluehr <kay.schlu...@g mx.netwrote:
>

On Dec 12, 7:34 am, sturlamolden <sturlamol...@y ahoo.nowrote:

I am not sure why a new type annotation syntax was needed Python 3:

>

Because people care about a feature when there is @syntax.

>
Good point; the inverse is not true though: time and time again people
cared about some syntax for properties without any change so far. The
result is a handful of different ways to spell out properties; python
2.6 will add yet another variation (http://mail.python.org/pipermail/
python-dev/2007-October/075057.html).
>
George

Yes, I'm aware. Curiously, whenever property syntax is discussed the
discussion loses track and is dragged away by needless side
discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
which he finally muses about replacing the class statement by the make
statement. So the PEP ended in "abstract nonsense" instead of
clarifying the point.

[1] http://www.python.org/dev/peps/pep-0359/

I vaguely remember a discussion a few years ago, where someone made
the quite reasonable suggestion of introducing some kind of
thunk_statement :

class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value

which was translated as follows:

class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk ())
del thunk

Now people started to consider using the compound statement within
expressions as well because the equal sign is used within method
signatures and call syntax. This lead to a general discussion about
the expr/statement distinction in Python, about multiline lambdas and
functional style programming. These association graphs are almost
predictable.

[Carl Friedrich Bolz]

Re: Is a &quot;real&quot ; C-Python possible?

sturlamolden wrote:

On 11 Des, 20:25, John Nagle <na...@animats. comwrote:
>

>Shed Skin effort. Its author writes "Am I the only one seeing the potential
>of an implicitly statically typed Python-like-language that runs at
>practically the same speed as C++?"

>
Don't forget about Pyrex and PyPy's RPython.
>
By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

I just want to stress that adding type hints _won't_ make programs
faster if you use a good specializing JIT compiler. Psyco in particular
would not benefit from type hints at all (even if you changed Psyco take
them into account) and would give you exactly the same speed as without
them.

Cheers,

Carl Friedrich Bolz

[Carl Friedrich Bolz]

Re: Is a &quot;real&quot ; C-Python possible?

sturlamolden wrote:

On 11 Des, 20:25, John Nagle <na...@animats. comwrote:
>

>Shed Skin effort. Its author writes "Am I the only one seeing the potential
>of an implicitly statically typed Python-like-language that runs at
>practically the same speed as C++?"

>
Don't forget about Pyrex and PyPy's RPython.
>
By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

I just want to stress that adding type hints _won't_ make programs
faster if you use a good specializing JIT compiler. Psyco in particular
would not benefit from type hints at all (even if you changed Psyco take
them into account) and would give you exactly the same speed as without
them.

Cheers,

Carl Friedrich Bolz

[George Sakkis]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 12, 4:09 am, Kay Schluehr <kay.schlu...@g mx.netwrote:

Curiously, whenever property syntax is discussed the
discussion loses track and is dragged away by needless side
discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
which he finally muses about replacing the class statement by the make
statement. So the PEP ended in "abstract nonsense" instead of
clarifying the point.
>
[1]http://www.python.org/dev/peps/pep-0359/

Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more. Alas, it was too much ahead of its time.. who knows, it might
revive on some 3.x version.

George

[sturlamolden]

Re: Is a &quot;real&quot ; C-Python possible?

On 12 Des, 12:56, George Sakkis <george.sak...@ gmail.comwrote:

Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more.

I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.

[Chris Mellon]

Re: Is a &quot;real&quot ; C-Python possible?

On Dec 12, 2007 8:36 AM, sturlamolden <sturlamolden@y ahoo.nowrote:

On 12 Des, 12:56, George Sakkis <george.sak...@ gmail.comwrote:
>

Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more.

>
I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.
>

You say that as if "one step closer to Lisp" is a worthwhile goal.

Python has not become what it is, and achieved the success it has,
because a bunch of people really wanted to use Lisp but didn't think
other people could handle it.

The goal of these sorts of discussions should be to make Python a
better Python. But what happens far too often (especially with
Lispers, but not just them by any means) is that people want to make
Python into a clone or "better" version of whatever other language
they like.

If you're the sort of person who views lisp as the goal that other
languages should aspire to, and I know many of those people exist and
even frequent this list, then you should probably spend your time and
energy on making Lisp a better Lisp and addressing whatever weaknesses
in Lisp have you using Python instead. Trying to fix Lisp (or
whatever) by transforming Python into it isn't going to make you any
happier, and it's just going to derail any discussion of making Python
a better *Python*.