

PEP 3146: Merge Unladen Swallow into CPython - dchest
http://svn.python.org/view/peps/trunk/pep-3146.txt?view=markup

======
JoachimSchipper
I don't really understand the politics surrounding Python, but I don't
understand why they believe this could be "blessed" by inclusion into the
repository.

Performance goals have not been met so far; it increases memory usage; PyPy is
an alternative with more community support (if only because the typical Python
programmer knows more Python than C++); and it makes the code much more
complex, introducing lots of hard-to-debug problems, at a time when the
developers already have trouble getting people to migrate to 3.x.

The 3.x branch does _not_ need a reputation for instability.

(None of this is to say Unladen Swallow is a bad idea, or should be killed;
but it should prove its worth first.)

~~~
garnet7
> but I don't understand why they believe this could be "blessed" by inclusion
> into the repository.

Google is, of course, a big company with lots of _very_ smart people, and they
rely on Python (and probably want to rely on it more in the future). Given
that they employ Guido and also the primary developers of Unladen, the chances
are very good that they will continue to vigorously improve upon it until
their performance goals are met.

As far as introducing C++ goes, it's going to stay roped off in LLVM land (see
[the PEP](<http://python.org/dev/peps/pep-3146/>) for details).

As far as community support, LLVM has plenty of that.

~~~
JoachimSchipper
Hmm, yes, I understand why the Unladen Swallow developers, and to a certain
extent Google, would want to do that. It just seems to me that the community
would benefit more by waiting a little.

By the developers' own admission, LLVM's JIT infrastructure is immature and
integrating it with Python uncovered lots of issues. Sure, clang has pretty
good community support, but that doesn't mean that the Python integration - or
even the JIT stuff - is equally well-supported. And the Python community
doesn't contain many LLVM experts, I'd wager.

------
kingkilr
A pretty, rendered version of the markup is available here:
<http://www.python.org/dev/peps/pep-3146/>

------
amix
I don't think it's enough to just add JIT. For a runtime system the garbage
collector is important, it's important to do optimizations such as V8's hidden
classes, function inlining, to remove the GIL etc. This is probably the reason
why their perfomance gain is so small - - they have added JIT, while applying
only a few smart optimizations.

I don't think Unladen Swallow should be merged into CPython until the benefits
are proven. Currently it will just add an extra layer of complexity, worsen
Python's greedy management of memory and add little benefits in perfomance.

------
aidenn0
I want a pony from Guido too

~~~
carbocation
Surprisingly on-topic :-) For the curious, the reference is within this
article: "We seek the following from the BDFL:

 _Approval for the overall concept of adding a just-in-time compiler to
CPython, following the design laid out below._

 _Permission to continue working on the just-in-time compiler in the CPython
source tree._

 _Permission to eventually merge the just-in-time compiler into the py3k
branch once all blocking issues have been addressed._

 _A pony._ "

------
IgorPartola
It's unfortunate that they never hit their original 5x performance boost.
Hopefully acceptance into CPython will help.

~~~
snprbob86
So is the goal to gain resources by becoming part of CPython? It seems like
the small performance increases they got are completely overshadowed by the
additional memory requirements. I don't pretend to understand the mainline
Python development cycle, but this surely doesn't seem mature enough to
justify declaring it as "the way forward".

~~~
jmatt
Ya I noticed that too. I'd love to have some performance benefits from JIT too
but not at those costs. 2.43x - 2.76x increase in memory to Django[1]. Ugh.
That's a large enough change that I'd have to upgrade hardware. Come on now.

[1] <http://www.python.org/dev/peps/pep-3146/#memory-usage>

~~~
alecthomas
From TFA "We view reducing memory usage as a blocking issue for final merger
into the py3k branch. "

~~~
IgorPartola
Down further they say something about how they'll ask the community what the
acceptable memory usage increase will be. In other words, they might reduce it
by say 15%, but not anywhere near the JIT-less levels, and call it a day. I
suppose you always have the option to compile python as --without-jit...

------
yoden
I think that a JIT compiler will eventually be added to python, so the sooner
this happens the better. The new generation of javascript engines (e.g. V8)
have shown us how fast dynamic code can be; there is no reason python can't
achieve this either. I also think the swallow team has gone about this in the
right way: presenting what they've done, and asking for what needs to happen
before it can become mainline. They obviously value this merge, so kudos to
google.

On the other hand, performance so far is quite underwhelming. Certainly, as a
PEP, this is by no means intended to be merged now, but to provide a roadmap
for the future. Here's to hoping they can remove their remaining roadblocks.

------
stuaxo
Until they get more performance out of it, it's way too marginal for the
memory used. If they can get it 2x the speed of CPython I'm all for it.

Of course one day pypy will emerge too, so unladen swallow should hurry up!

(TBH I'd prefer pypy to become the canonical python in the end)

------
luismgz
Sorry but I need to know this: What does "Pony" mean in a nerdy-geek humor
context?

~~~
prodigal_erik
"... and a pony" is just an admission that you've already asked a lot and it
might not happen. A pony is the kind of thing a child requests on a whim, who
is then crushed because they don't understand how ridiculously impractical it
would be.

~~~
luismgz
Thanks. That's a very good answer :-)

------
abdulhaq
If it was at terminal velocity it should be considered, but it's yet to get
off the ground. Until then, psyco is a great JIT compiler that really works.

------
wanderr
...African or European?

