6 ms·

No, it's not dead, and I'm sad that this is sitting at the front page, because it's so misleading. The fact is, it's stalled (https://www.google.com/buzz/bcann

by jnoller 16y ago

No, it's not dead, and I'm sad that this is sitting at the front page, because it's so misleading. The fact is, it's stalled (https://www.google.com/buzz/bcannon/bZDN1jNZ3uC/Is-this-finally-going-to-push-CPython-into-the https://www.google.com/buzz/bcannon/bZDN1jNZ3uC/Is-this-fina...) - http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ was accepted. This means that a branch was made with the intent of merging US into Py3k. Unfortunately, this proved to be a greater task then originally planned. Stalled != Dead. To quote Collin: "Unladen Swallow is stalled because merging the code into the py3k-jit branch plain sucks: lots of new compatibility work to be done, lots of corners we had to un-cut, lots of drudge and suffering. It doesn't help that Google is full of far more interesting and influential projects." So add in the fact that the resources Google had "assigned" to the project got moved/reassigned onto something else, and what you have is a very stalled project. Collin has stated that they hope(d) that other python-core devs would/will step up to help, but everyone is pretty tapped out as it is. I'm as disappointed as anyone that it's stalled - given it's compatibility with C extensions, potential speedups and future potential, it has been one of the projects I've had the most hope for. That said, PyPy is also coming along; when they hit 2.7 compatibility and they have drop-in replacement capability, the ecosystem will be very interesting. Competition in the interpreter space is good, and I feel that Unladen's aggressiveness helped spur/move PyPy along. That said Unladen (in my mind) remains the CPython interpreter's best way of moving into the future. It still has the most promise for that code base.

Estragon 16y ago
"Look matey, I know a dead swallow when I see one, and I'm looking at one right now. The plumage don't enter into it. It's stone dead!"
- stcredzero 16y ago
  Wrong bird and wrong python. (The latter is meant in both ways!)
  - deleted 16y ago
    [deleted]
ot 16y ago
jnoller, I may have indulged in catchiness at the expense of accuracy and I am sorry if the title is misleading. I hoped that this thread would raise some discussion about the status of US, as, after a lot of publicity on project launch, there have not been many official statements from the team. I have followed the project since the beginning and saw the exponential decay of traffic in the mailing list and commits as the promised performance improvements seemed less achievable (but it has to be said that the US team contributed to LLVM a lot of useful code, like gdb debugging of JITted code). So my question is: why is US relevant since it hasn't achieved any significant performance boost? Why should we believe in the "potential speedups and future potential" if there is no evidence that supports them? I myself had done some experiments with implementing a python JIT with LLVM some time before US was launched and had the same results, 10-15% improvement on microbenchmarks at expense of huge memory increase and compilation times.(see https://groups.google.com/d/topic/unladen-swallow/bqf9TzWHhts/discussion https://groups.google.com/d/topic/unladen-swallow/bqf9TzWHht... ) It seems that the bottleneck is not in the interpreter loop, but in the CPython runtime API. I am afraid that, if the interpreter has to stick to CPython source compatibility, it cannot get rid of the overhead. But I would be very happy to be proven wrong.
- jnoller 16y ago
  When asked - on the mailing list, on google buzz, or anywhere else, Collin and Jeffery and others have been very open about its status. They've always dealt us (as the community) a fair hand about the status of the project, and the path moving forward. Your indulgence in catchiness is annoying, as it will be echoed (and it already has been) all over the place with breathless drama "Look! It's Dead!" when, despite languishing, the code is still there, still functional, but starved of resources. The editorializing is frustrating, misleading and overall, I think harmful. As for why it's still relevant: Easy, it's the only currently visible way of moving the CPython interpreter forward from an evolution standpoint. US does show a series of speedups, one thats useful for CPython. To quote: "A JIT compiler is an extremely flexible tool, and we have by no means exhausted its full potential. Unladen Swallow maintains a list of yet-to-be-implemented performance optimizations [49] that the team has not yet had time to fully implement. Examples:" - http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ I would recommend: if you want to move anything forward, or help, rather than make posts like this, jump in on the http://svn.python.org/view/python/branches/py3k-jit/ http://svn.python.org/view/python/branches/py3k-jit/ Yes; part of the reason the current interpreter is limited is due to backwards compatibility, but I'd rather have a limited JIT with some performance gains then none at all. The fundamental issue is that Jeffery, Collin and Reid - the founding three are "off in the woods" - and they're the only ones who understand the code enough to move it forward right now. PyPy's success(es) are orthogonal to the evolution of the CPython interpreter code base.

by jnoller 16y ago

Estragon 16y ago

"Look matey, I know a dead swallow when I see one, and I'm looking at one right now. The plumage don't enter into it. It's stone dead!"

stcredzero 16y ago
Wrong bird and wrong python. (The latter is meant in both ways!)
- deleted 16y ago
  [deleted]

ot 16y ago

jnoller, I may have indulged in catchiness at the expense of accuracy and I am sorry if the title is misleading. I hoped that this thread would raise some discussion about the status of US, as, after a lot of publicity on project launch, there have not been many official statements from the team. I have followed the project since the beginning and saw the exponential decay of traffic in the mailing list and commits as the promised performance improvements seemed less achievable (but it has to be said that the US team contributed to LLVM a lot of useful code, like gdb debugging of JITted code). So my question is: why is US relevant since it hasn't achieved any significant performance boost? Why should we believe in the "potential speedups and future potential" if there is no evidence that supports them? I myself had done some experiments with implementing a python JIT with LLVM some time before US was launched and had the same results, 10-15% improvement on microbenchmarks at expense of huge memory increase and compilation times.(see https://groups.google.com/d/topic/unladen-swallow/bqf9TzWHhts/discussion https://groups.google.com/d/topic/unladen-swallow/bqf9TzWHht... ) It seems that the bottleneck is not in the interpreter loop, but in the CPython runtime API. I am afraid that, if the interpreter has to stick to CPython source compatibility, it cannot get rid of the overhead. But I would be very happy to be proven wrong.

jnoller 16y ago
When asked - on the mailing list, on google buzz, or anywhere else, Collin and Jeffery and others have been very open about its status. They've always dealt us (as the community) a fair hand about the status of the project, and the path moving forward. Your indulgence in catchiness is annoying, as it will be echoed (and it already has been) all over the place with breathless drama "Look! It's Dead!" when, despite languishing, the code is still there, still functional, but starved of resources. The editorializing is frustrating, misleading and overall, I think harmful. As for why it's still relevant: Easy, it's the only currently visible way of moving the CPython interpreter forward from an evolution standpoint. US does show a series of speedups, one thats useful for CPython. To quote: "A JIT compiler is an extremely flexible tool, and we have by no means exhausted its full potential. Unladen Swallow maintains a list of yet-to-be-implemented performance optimizations [49] that the team has not yet had time to fully implement. Examples:" - http://www.python.org/dev/peps/pep-3146/ http://www.python.org/dev/peps/pep-3146/ I would recommend: if you want to move anything forward, or help, rather than make posts like this, jump in on the http://svn.python.org/view/python/branches/py3k-jit/ http://svn.python.org/view/python/branches/py3k-jit/ Yes; part of the reason the current interpreter is limited is due to backwards compatibility, but I'd rather have a limited JIT with some performance gains then none at all. The fundamental issue is that Jeffery, Collin and Reid - the founding three are "off in the woods" - and they're the only ones who understand the code enough to move it forward right now. PyPy's success(es) are orthogonal to the evolution of the CPython interpreter code base.