Live data from Hacker News

PEP 3146: Merge Unladen Swallow into CPython

svn.python.org

11–20 of 34 posts

Re: PEP 3146: Merge Unladen Swallow into CPython

#11

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

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

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

Re: PEP 3146: Merge Unladen Swallow into CPython

#13
post #11

Earlier quoted context omitted.

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

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

Re: PEP 3146: Merge Unladen Swallow into CPython

#14
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)

Re: PEP 3146: Merge Unladen Swallow into CPython

#15
post #11

Earlier quoted context omitted.

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

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

Extra memory means a longer start-up time (for small apps) ala JVM, and makes hosting much more expensive. Lots of web hosts are memory / IO bound, not CPU bound. And you are sacrificing memcache size for python speed if you increase python's footprint - not always a winner.

Re: PEP 3146: Merge Unladen Swallow into CPython

#16
post #11

Earlier quoted context omitted.

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

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

Well, they've still got at least a year or so to work on it, since it's unlikely Django will be running on Python 3 before then...

Re: PEP 3146: Merge Unladen Swallow into CPython

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

Re: PEP 3146: Merge Unladen Swallow into CPython

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

Post reply on HN