Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 3146: Merge Unladen Swallow into CPython

svn.python.org

Post reply on HN
Print view View original

21–30 of 34 posts

Re: PEP 3146: Merge Unladen Swallow into CPython

#21

Post by algorias »

alecthomas wrote: post #13
jmatt wrote: post #11

Earlier quoted context omitted.

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

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

So, you'd accept unladen as the official JIT based on the vague promise of improving its glaring issues sometime in the future? Does that give it the right to be in a "blessed" repo?

I propose my own python implementation for acceptance into the source tree. Right now, it's a single empty file (but I've got lots of ideas!). I'll even consider it a blocking issue if it achieves less than 10x speedup using half as much memory.

Re: PEP 3146: Merge Unladen Swallow into CPython

#22

Post by IgorPartola »

alecthomas wrote: post #13
jmatt wrote: post #11

Earlier quoted context omitted.

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

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

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...

Re: PEP 3146: Merge Unladen Swallow into CPython

#23

Post by algorias »

JoachimSchipper wrote: post #18

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…

I agree. Why are they in such a rush to get into trunk? The work they're doing is great, but their sense of entitlement about is is a bit misplaced.

Re: PEP 3146: Merge Unladen Swallow into CPython

#24

Post by JoachimSchipper »

algorias wrote: post #23
JoachimSchipper wrote: post #18

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…

I agree. Why are they in such a rush to get into trunk? The work they're doing is great, but their sense of entitlement about is is a bit misplaced.

This is speculation, but: Google is paying some people actual money to work on Unladen Swallow. People who have made bold claims about the performance improvements, which, apparently, were not entirely justified.

I imagine that it would be politically desirable to show success by getting officially blessed, and it would also mean that the project wouldn't just stagnate if the people now working on it were told to do something else.

More optimistically, they acknowledge that more coders would be welcome, and hope that it's easier to find those after being included in the main repository. It would also give them an edge over PyPy, their sort-of-competitor.

Re: PEP 3146: Merge Unladen Swallow into CPython

#26

Post by garnet7 »

JoachimSchipper wrote: post #18

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…

> 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.

Re: PEP 3146: Merge Unladen Swallow into CPython

#27

Post by garnet7 »

IgorPartola wrote: post #6

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

> It's unfortunate that they never hit their original 5x performance boost.

Give 'em a chance. They're only just out of the gate. :)

Re: PEP 3146: Merge Unladen Swallow into CPython

#29

Post by JoachimSchipper »

garnet7 wrote: post #26
JoachimSchipper wrote: post #18

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…

> 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 performan…

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.

Re: PEP 3146: Merge Unladen Swallow into CPython

#30

Post by luismgz »

JoachimSchipper wrote: post #18

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…

Very simple: this is a PEP to improve the state of "Cpython" (this is the main python implementation right now, and has been since the invention of python).

Pypy, on the other hand, is a new implementation of Python (just like ironpython or jython), and it could eventually replace cpython in the future if it proves to be succesfull (although it would be a long way off).

In few words: Python, the language, have many implementations. Cpython is the current reference one. Unladen Swallow aims to improve it, not to replace it. Actually, even the US developers acknowledge that Pypy (or any other succesfull implementation that may come up) is the future, because it doesn't have to bear the burden imposed by the c platform.

Post reply on HN