Python un-plugging the Interpreter

[John Nagle]

Hi All,
I was thinking about the feasbility of adjusting Python as a
compiled language. Being said that I feel these are the following
advantages of doing so --
1) Using the powerful easy-to -use feature of Python programming
language constructs.
2) Making the program to run at par with the compiled version of C/C++
program- this is the main benefit which can be derived out of this.
3) Highly re-use existing Python code for High performance application.
4) Acheive true parallelism and performance by getting rid of the
middle-man Interpreter and GIL.

I know this must be appearing like a foolish idea. But I would like to
know the opinion of people who might have thought about it.

It's a great idea. Look at ShedSkin, PyPy, and Jython, all of
which tried to do it, and none of which really became finished
products.

John Nagle

 

[S.Mohideen]

Hi All,
I was thinking about the feasbility of adjusting Python as a
compiled language. Being said that I feel these are the following advantages
of doing so --
1) Using the powerful easy-to -use feature of Python programming language
constructs.
2) Making the program to run at par with the compiled version of C/C++
program- this is the main benefit which can be derived out of this.
3) Highly re-use existing Python code for High performance application.
4) Acheive true parallelism and performance by getting rid of the
middle-man Interpreter and GIL.

I know this must be appearing like a foolish idea. But I would like to know
the opinion of people who might have thought about it.

Thanks
Moin

 

[Steve Holden]

It's a great idea. Look at ShedSkin, PyPy, and Jython, all of
which tried to do it, and none of which really became finished
products.

That's not really fair. ShedSkin and PyPy are still works in progress.
Jython was feature-complete, and has merely suffered from delayed
maintenance - the current maintainers are getting closer to current
language standards as we speak. Even CPython is a worl in progress eben
though it's normally treated as the reference implementation.

The one compiling implementation you don't mention, of course, is
IronPython. This compiles to the .NET/Mono CLR, which in turn can use
JIT techniques to generate machine code that the runtime will cache und
er the right circumstances.

Overall, then, I think the picture's a little rosier than you paint it
even though there's always room for improvement.

regards
Steve

 

[Michael Hoffman]

I was thinking about the feasbility of adjusting Python as a
compiled language.

In addition to the Python compilers listed by Steve, there is also
Pyrex, which translates a Python-like language to C, and allows one to
interact with it from Python with very little difficulty.

 

[Steven Bethard]

I was thinking about the feasbility of adjusting Python as a
compiled language.

Python is a compiled language. It's compiled from source code to byte
code. That's what the .pyc files are.

STeVe

 

[Jorgen Grahn]

Hi All,
I was thinking about the feasbility of adjusting Python as a
compiled language. Being said that I feel these are the following advantages
of doing so --
1) Using the powerful easy-to -use feature of Python programming language
constructs.

We already do.

2) Making the program to run at par with the compiled version of C/C++
program- this is the main benefit which can be derived out of this.

Depends on what you mean by 'at par'. In the general case, that code
would have to basically work like the Python interpreter. Too much is
happening at runtime and it cannot be determined at compile time.

3) Highly re-use existing Python code for High performance application.

A reformulation of (2).

4) Acheive true parallelism and performance by getting rid of the
middle-man Interpreter and GIL.

Is the GIL really an artifact of the interpreter?

/Jorgen

 

[Steve Holden]

Is the GIL really an artifact of the interpreter?

In so far as only the CPython interpreter has one, I'd have to say "yes"
to this. It's used to make various operations trivially thread-safe,
which allows large speed gains in the programming.

A long time ago Greg Stein produced a patch that removed the need for
the GIL, but nobody seemed to want to pay the penalty it extracted in
speed reduction, so it languished unadopted.

regards
Steve

 

[Alex Martelli]

In addition to the Python compilers listed by Steve, there is also
Pyrex, which translates a Python-like language to C, and allows one to
interact with it from Python with very little difficulty.

....and Boo, which is kind of a Python dialect in the same sense as Pyrex
is, but has type inference as well as declarations, and (there being
only one current implementation) compiles into good dotNet code.


Alex

 

[Alex Martelli]

A long time ago Greg Stein produced a patch that removed the need for
the GIL, but nobody seemed to want to pay the penalty it extracted in
speed reduction, so it languished unadopted.

Perhaps the current wave of dual-core and quad-core CPUs in cheap
consumer products would change people's perceptions -- I wonder...


Alex

 

[Steve Holden]

Perhaps the current wave of dual-core and quad-core CPUs in cheap
consumer products would change people's perceptions -- I wonder...

It would be nice to see the GIL banished, but the impression I get from
my (limited) acquaintance with the Python 3.0 world leads me to believe
that its banishment is *not* being treated as a priority.

I can understand that it would be a major engineering effort, but I
should have thought the returns on multi-core architectures would have
been worth considering.

It's going to be interesting to see whether perceptions in the CPython
world change as PyPy and IronPython progress.

regards
Steve

 

[Jorgen Grahn]

Perhaps the current wave of dual-core and quad-core CPUs in cheap
consumer products would change people's perceptions -- I wonder...

Maybe it would change /perceptions/, but would normal users suddenly
start running things that are (a) performance-critical, (b) written in
Python and (c) use algorithms that are possible to parallellize?

I doubt it. (But I admit that I am a bit negative towards thread
programming in general, and I have whined about this before.)

/Jorgen

 

[Steve Holden]

Maybe it would change /perceptions/, but would normal users suddenly
start running things that are (a) performance-critical, (b) written in
Python and (c) use algorithms that are possible to parallellize?

I doubt it. (But I admit that I am a bit negative towards thread
programming in general, and I have whined about this before.)

Well there seems to be little doubt that the rise in clock speeds is
reaching a plateau, so it seems like parallelization will have to be the
long-term trend. It's difficult to perform a deep enough static analysis
of programs in dynamic languages to automatically parallelize the code
(it's hard enough for languages like Fortran), but I am sure that over
the next few years languages will start to sprout features that make
programmer-directed parallelization easier.

I'd like to see Python leading that charge, not failing to track it. So,
stop being a Luddite ;-)

regards
Steve

 

[Alex Martelli]

Maybe it would change /perceptions/, but would normal users suddenly
start running things that are (a) performance-critical, (b) written in
Python and (c) use algorithms that are possible to parallellize?

That depends on what "normal" means. For the common definition (users
that don't _write_ programs), it would depend on what ``developers''
release to the world.

I doubt it. (But I admit that I am a bit negative towards thread
programming in general, and I have whined about this before.)

I'm no big fan of threading either, believe me. But with multi-core
CPUs onrushing, exploiting them requires either that or multiple
processes; and, with Windows still prevalent and not exactly a speed
daemon in dealing with processes (while pretty good with threads), it
would appear likely that threading's here to stay.

IronPython would appear to be coming along nicely and getting acceptance
in the Windows community, and I believe the underlying dotNet CLR does
do threads nicely; we'll see what develops on that front, I guess.


Alex

 

[John Nagle]

IronPython would appear to be coming along nicely and getting acceptance
in the Windows community, and I believe the underlying dotNet CLR does
do threads nicely; we'll see what develops on that front, I guess.

Thus we now have a demonstration that Python implementations need
not be as slow as CPython. And that Microsoft is beating open source
on Python.

Python as a language is in good shape. But the CPython
implementation is holding back progress. What we need are better
and faster implementations of the language we've got.

PyPy, ShedSkin, and Jython all were steps in the right
direction, but none had enough momentum to make it.
Jython hasn't had a release since 2002, ShedSkin is basically
one guy, and the EU pulled the plug on PyPy.

Now what?

John Nagle

 

[Alex Martelli]

Thus we now have a demonstration that Python implementations need
not be as slow as CPython. And that Microsoft is beating open source
on Python.

Not yet -- overall, CPython is still faster than IronPython in a vast
majority of cases. Also, according to
<http://www.codeplex.com/Project/License.aspx?ProjectName=IronPython>:
"""
You may use the Software for any commercial or noncommercial purpose,
including distributing derivative works
...
This license has not been submitted to OSI, but it allows developers to
take full advantage of a dynamic language on the CLR and to have the
freedom to distribute their works for the benefit of the community at
large. The license is half of a page long and very straight forward. We
believe it stands up to what developers demand of an "open" license.
"""
I.e., they're claiming that, while not OSI-approved, theirs _IS_ in
essence an open-source license.

Python as a language is in good shape. But the CPython
implementation is holding back progress. What we need are better
and faster implementations of the language we've got.

That's not what Guido thinks -- he thinks we first need a better version
of the language (Python 3000), simplified by removing much of the stuff
that's been hanging around forever for backwards compatibility (and with
a few other enhancements, check the Py3k PEPs). As long as the
volunteers who work on Python prefer to follow Guido's leadership rather
than yours, it's going to be difficult to force them to do what _you_
think is most important, rather than what _he_ thinks is.

PyPy, ShedSkin, and Jython all were steps in the right
direction, but none had enough momentum to make it.
Jython hasn't had a release since 2002, ShedSkin is basically
one guy, and the EU pulled the plug on PyPy.

Now what?

If you can get enough people to agree with you, and those people have
either technical nous and spare time, or some money and the willingness
to invest it in funding a new Python implementation (presumably building
on top of PyPy's excellent final deliverables), you can get a team
together for the purpose. Or, if you're really enthusiastic about
IronPython, you could look into supporting Mono
(<http://www.mono-project.com/Main_Page>) to make it ever better, and a
faster platform for running IronPython-compiled applications than
Microsoft's own proprietary CLR (and also modify IronPython as you
require, given the above-mentioned license).

Other possible alternative starting points include pirate (the Python
compiler for the Parrot virtual machine) -- I don't believe it's
currently under active development (no more than, say, Jython), but I
might well be wrong on this issue; and "Python dialects" ranging from
Pyrex to Boo.


Alex

 

[Hendrik van Rooyen]

Maybe it would change /perceptions/, but would normal users suddenly
start running things that are (a) performance-critical, (b) written in
Python and (c) use algorithms that are possible to parallellize?

I doubt it. (But I admit that I am a bit negative towards thread
programming in general, and I have whined about this before.)

I find this last statement interesting, because it differs so much
from my own attitude - getting a thread running was one of the
first things I did when I started getting to grips with python.

Do you mind "whining" some more - maybe I can learn
something - threads seem to me to make a lot of things so
much easier and more natural, as I see them as sequences
that run "at the same time", and I find this immensely useful
for all sorts of things, as it enables me to think in a simple
linear fashion about parts of complicated things. And if you
add queues, you have something in your hand that you can
do quite fancy stuff with in a robust, simple manner...

*grin* before I discovered the queue module, I was using
named pipes to communicate between threads...

So you could say I am a threading freak if you want to, and
I won't argue.

But I would like to hear the opposite viewpoint..

- Hendrik

 

[Steve Holden]

Thus we now have a demonstration that Python implementations need
not be as slow as CPython. And that Microsoft is beating open source
on Python.

Well, let's remember that a) IronPython was originally developed
independently of Microsoft, and b) it's still open source or close to it
(I.'m not familiar with the OSI's opinion on the license Microsoft use
to distribute IronPython, but the fact it can be included in the FePy
distribution bodes well).

Python as a language is in good shape. But the CPython
implementation is holding back progress. What we need are better
and faster implementations of the language we've got.

Hear, hear!

PyPy, ShedSkin, and Jython all were steps in the right
direction, but none had enough momentum to make it.
Jython hasn't had a release since 2002, ShedSkin is basically
one guy, and the EU pulled the plug on PyPy.

Hey there, loose talk costs lives, you know. That is a complete
mischaracterization of the true position.

Progress on Jython may not have been stellar, but it has occurred and is
ongoing. Yes, Shedskin is "one guy", but so was Psyco and that was (and
remains) a useful tool.

As far as I am aware the PyPy project has come to the end of its initial
EU funding, and they chose to focus on producing deliverables close to
the end of the project phase rather that divert effort into securing
ongoing funding. So nobody has "pulled the plug", and I believe there is
every possibility of a further round of funded research and development
in the future. Certainly the results to date would justify that action
on the part of the EU. I don't know if and when the request for further
funding will be submitted.

Now what?

Work continues. Rome wasn't built in a day, you know.

regards
Steve

 

[cfbolz]

Hear, hear!


Hey there, loose talk costs lives, you know. That is a complete
mischaracterization of the true position.
Indeed!

Progress on Jython may not have been stellar, but it has occurred and is
ongoing. Yes, Shedskin is "one guy", but so was Psyco and that was (and
remains) a useful tool.

As far as I am aware the PyPy project has come to the end of its initial
EU funding, and they chose to focus on producing deliverables close to
the end of the project phase rather that divert effort into securing
ongoing funding. So nobody has "pulled the plug", and I believe there is
every possibility of a further round of funded research and development
in the future. Certainly the results to date would justify that action
on the part of the EU. I don't know if and when the request for further
funding will be submitted.

Indeed here too. "pulling the plug" sounds like an extremely unfair
description. There never was the plan to get funding longer than what
we got so far (at least not with additional action from our side). And
yes, there is the possibility of getting additional funding in the
future, although we are not concretely thinking about it yet.

Apart from that, work on PyPy is definitely continuing, at least after
the much needed break most PyPy-developers are currently taking to
recover from the stress of the EU project (yes, funding has its
downsides too).

Cheers,

Carl Friedrich

 

[Jorgen Grahn]

I find this last statement interesting, because it differs so much
from my own attitude - getting a thread running was one of the
first things I did when I started getting to grips with python.

Do you mind "whining" some more - maybe I can learn
something - threads seem to me to make a lot of things so
much easier and more natural, as I see them as sequences
that run "at the same time", and I find this immensely useful
for all sorts of things, as it enables me to think in a simple
linear fashion about parts of complicated things.

It's the other way around for me -- using a threaded design looks
superficially more linear, but all the complexity is still there, and
then some. I mean, threads are well known for causing surprising and
hard-to-track-down (and hard to trigger!) bugs and performance
problems.

(I'm comparing with the Unix select() call, and I assume the APIs I
want to use are designed to work with select(). i.e. use select()able
file descriptors.)

And if you
add queues, you have something in your hand that you can
do quite fancy stuff with in a robust, simple manner...

*grin* before I discovered the queue module, I was using
named pipes to communicate between threads...

So you could say I am a threading freak if you want to, and
I won't argue.

But I would like to hear the opposite viewpoint..

Good. My viewpoint is due to my Unix background (but I'm not
insinuating that all Unix users dislike threads).

Eric Raymond's "The Art of Unix Programming" sums up the threading
criticism, I think:

http://catb.org/~esr/writings/taoup/html/multiprogramchapter.html

/Jorgen

 

[Jorgen Grahn]

That depends on what "normal" means.

I used your phrase "cheap consumer products" to the max -- defining
"normal users" as people who wouldn't have used an SMP machine two
years ago, and don't actively choose dual core today (or choose it
because they like HP's tandem bike ads).

For the common definition (users
that don't _write_ programs), it would depend on what ``developers''
release to the world.

I doubt it. (But I admit that I am a bit negative towards thread
programming in general, and I have whined about this before.)

I'm no big fan of threading either, believe me. But with multi-core
CPUs onrushing, exploiting them requires either that or multiple
processes [...]

Yes. But that's where the current "concurrent programming craze" seems
so odd to me. It's as if the reasoning goes:

"New machines are multi-core; thus we have to find first a reason,
then a way to exploit them, on the process level".

Personally, I'm rarely CPU bound in my work, so I have a hard time
finding that reason. I doubt even Windows users are CPU bound, except
when a program hangs at 100% CPU.

When I get a multi-core CPU eventually, those other CPUs will mostly
do kernel-space tasks, offload things like rendering windows and doing
ssh encryption/compression, and let me type "make -j2" to compile my C
source code faster. No threading is needed for those things. (And even
if it was, I doubt anyone would rewrite either the Linux kernel, X11,
ssh or make in Python ;-)

BR,
/Jorgen